🦋 Changeset detected

Latest commit: 6e634d2

The changes in this PR will be included in the next version bump.

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

@Sh031224 Thanks for contributing this! I'd really like this feature.
Question though:
Can I select the package using glob --patch @pkg-*?

@Sh031224 Thanks for contributing this! I'd really like this feature. Question though: Can I select the package using glob --patch @pkg-*?

I hadn't thought of a way to use glob.
I'll add it to the commit with an additional implementation!

@1oglop1
I've pushed an extra commit so you can use it with the globs you said!

I would like to also see a flag for the name of generated file, in case user doesn't want to have it randomly generated

I would like to also see a flag for the name of generated file, in case user doesn't want to have it randomly generated

I didn't quite understand what you meant. Can you explain in more detail?

As a personal preference, I use changeset files not with randomized .changesets/unicorn-in-space.md but with some more meaningful unique names like .changesets/Issue1337.md

So I would be happy to see --filename foo which would create .changesets/foo.md instead of .changesets/wooden-icecream.md

What is the status of this pull request? Is there any chance it will be merged soon?

// EDIT
I'm testing this feature, and everything works fine except that the final confirmation is still required:

🦋  Note: All dependents of these packages that will be incompatible with
🦋  the new version will be patch bumped when this changeset is applied.
🦋
🦋  Is this your desired changeset? (Y/n) › true

It would be great if there were an additional flag like --yes or --auto-approval so that we can apply changesets without any user interactions.

We can use a workaround by piping yes y to changesets, e.g.:

yes y | changesets add --message "My message" --patch @my/package

but it's kinda hacky.

What is the status of this pull request? Is there any chance it will be merged soon?

// EDIT I'm testing this feature, and everything works fine except that the final confirmation is still required:

🦋  Note: All dependents of these packages that will be incompatible with
🦋  the new version will be patch bumped when this changeset is applied.
🦋
🦋  Is this your desired changeset? (Y/n) › true

It would be great if there were an additional flag like --yes or --auto-approval so that we can apply changesets without any user interactions.

We can use a workaround by piping yes y to changesets, e.g.:

yes y | changesets add --message "My message" --patch @my/package

but it's kinda hacky.

I would like to develop this PR further if I receive feedback from maintainers.

Is this PR still being tracked so it can me merged and used soon?

@Sh031224, is there any chance you could resolve the merge conflicts? Then we would be able to apply these changes with the yarn / pnpm patch feature.

Currently, I'm using my private fork of your PR.

@Sh031224, is there any chance you could resolve the merge conflicts? Then we would be able to apply these changes with the yarn / pnpm patch feature.

Currently, I'm using my private fork of your PR.

Merge conflicts were resolved by reflecting the latest code.

If you have any problems, please let me know.

Is this PR still being tracked so it can me merged and used soon?

Maintainer doesn't seem to be interested in this PR at all. There isn't even an opinion.

This is a pity. For those of us wanting to automate workflows, especially if we're not on github, this sort of feature is necessary

There's a workaround for forking this repo; yarn and pnpm support patching dependencies.

What's the progress of this issue?
We want could have these flags to support Jenkins pipeline usage.

This PR's merge is a urgent requirement for me to automate changeset cli workflows.

long waiting for this PR be merged, really need it in CI/CD.

can we merge this PR @Andarist ?

@Andarist I will pay you $100 USD to merge this PR

I will chip in another $2

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.45%. Comparing base (4c26f2f) to head (6e634d2).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1121      +/-   ##
==========================================
+ Coverage   87.31%   87.45%   +0.13%     
==========================================
  Files          71       71              
  Lines        2546     2582      +36     
  Branches      681      690       +9     
==========================================
+ Hits         2223     2258      +35     
- Misses        299      300       +1     
  Partials       24       24              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

feel free to toss us some pennies to via OpenCollective or GH Sponsors 😉

It would be much better if you don't have to repeat --major, --minor, or --patch multiple times by allowing the separation by commas (e.g. --minor pkg1,pkg2 --patch pkg3,pkg4 instead of --minor pkg1 --minor pkg2 --patch pkg3 --patch pkg4).

It would be much better if you don't have to repeat --major, --minor, or --patch multiple times by allowing the separation by commas (e.g. --minor pkg1,pkg2 --patch pkg3,pkg4 instead of --minor pkg1 --minor pkg2 --patch pkg3 --patch pkg4).

please open a new issue and so we can track this!

Created #2134

@Andarist Thank you for merging this! As promised sent the $100 via GH Sponsors. Thanks for all the work you do to maintain this!

done too 🤣

Thanks to the goat @Andarist 🙏🏼

https://x.com/wuweiweiwu/status/2072016283726655639?s=20

Note that we now have a wonderful team, and it's best to sponsor Changesets work using our OpenCollective