Conversation
🦋 Changeset detectedLatest commit: ee4445b The changes in this PR will be included in the next version bump. This PR includes changesets to release 15 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The failing tests and Typecheck are the same as at current state of "main" branch, so it seems to be unrelated to the feature I added |
29b6298 to
52ebe83
Compare
fc85529 to
52f1228
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1720 +/- ##
==========================================
+ Coverage 81.33% 81.69% +0.35%
==========================================
Files 54 55 +1
Lines 2277 2409 +132
Branches 684 726 +42
==========================================
+ Hits 1852 1968 +116
- Misses 420 436 +16
Partials 5 5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
52f1228 to
ee4445b
Compare
|
please merge this PR - this would be super helpful :) |
| await addChangeset(cwd, { auto: true }, mockConfig); | ||
|
|
||
| // Verify both packages were processed | ||
| expect(mockExecSync).toHaveBeenCalledWith( |
There was a problem hiding this comment.
I think here the comment is not matching this expectation (or at least the expectation is not specific enough). Can it be more specific?
| await addChangeset(cwd, { auto: true }, mockConfig); | ||
|
|
||
| // Verify the function correctly identified conventional vs non-conventional commits | ||
| expect(mockExecSync).toHaveBeenCalledWith( |
There was a problem hiding this comment.
I think here the comment is not matching this expectation (or at least the expectation is not specific enough). Can it be more specific?
|
|
||
| // Verify breaking change was detected | ||
| expect(mockExecSync).toHaveBeenCalledWith( | ||
| "git tag --list --sort=-v:refname", |
| await addChangeset(cwd, { auto: true }, configWithMaxCommits); | ||
|
|
||
| // Verify the function respected the maxCommits setting | ||
| expect(mockExecSync).toHaveBeenCalledWith( |
|
|
||
| const mockExecSync = execSync as jest.MockedFunction<typeof execSync>; | ||
|
|
||
| describe("Auto Mode - Integration Tests", () => { |
There was a problem hiding this comment.
Why are there two integration tests files for auto mode? Should these files be merged?
| await addChangeset(cwd, { auto: true }, mockConfig); | ||
|
|
||
| // Verify git commands were called correctly | ||
| expect(mockExecSync).toHaveBeenCalled(); |
There was a problem hiding this comment.
Should this expectation be more specific, as it was done on the previous test?
| await addChangeset(cwd, { auto: true }, mockConfig); | ||
|
|
||
| // Verify git commands were called correctly | ||
| expect(mockExecSync).toHaveBeenCalled(); |
| "description": "Conventional commit preset to use", | ||
| "default": "conventionalcommits" | ||
| } | ||
| } |
There was a problem hiding this comment.
Missing the analyzer? Or is it not part of the official configuration?
| maxCommits?: number; | ||
| /** Conventional commit preset to use (default: "conventionalcommits") */ | ||
| preset?: string; | ||
| /** Custom analyzer function for commit analysis */ |
There was a problem hiding this comment.
| /** Custom analyzer function for commit analysis */ | |
| /** Custom analyzer function for commit analysis (for testing) */ |
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Should analyzer also be validated? Or is it not part of the official configuration?
|
@bluwy Can you also take a look? |
|
Sorry, I'm not really interested in the feature request but if other maintainers think otherwise I'm happy to lend a review. At first it felt tedious to me too that changesets didn't rely on conventional commits for changes, but after getting used to it, I much prefer how it doesn't tie changes to git commits and that it encourages better changelogs. |
|
@bluwy counter points from someone who is fairly new to the changesets:
Obviously, if you commit every single line of code, your commit messages are only "wip" or you have dozens of commits because you work on a new feature then this mode has little to no value because it will create noise. I would say a more valid reason not to support this is a maintenance burden. Personally, I do see a value for this mode for aforementioned points knowing I could simply do |
|
This feature would be fantastic for my current workflow and I am in full support of it - but this voice is coming from a non maintainer (right now). I enforce conventional commits, and I generally make my changers from my commits + a light summary sometimes. It would be ideal to have an --auto mode which allows the changset to be inferred from the commits. |
Auto Mode Feature Implementation
Overview
This PR implements an auto mode feature for Changesets that automatically generates changesets based on conventional commit analysis.
Key Features
--autoflag forchangeset addcommand@semantic-release/commit-analyzerusingconventionalcommitspresetmaxCommits,preset, and customanalyzeroptionsTechnical Implementation
packages/cli/src/commands/add/auto-mode.ts- Main auto-mode logicpackages/cli/src/commands/add/semanticAnalyzer.ts- Commit analysis integrationConfiguration & Usage
Configure via
"auto": { "maxCommits": 100, "preset": "conventionalcommits" }in.changeset/config.json. (standart path)Usage:
npx changeset add --autoFixes issues
fixes #862
#1504#1698