[Umbrella] Changesets v3

@mitchellhamilton

For now, I'd like to just open this as a placeholder issue, I will gather things here over time. You can mention whatever improvements you would like to see in Changesets, maybe even what we should remove/deprecate.

Note that there is no rush in moving this forward any time soon. This is more like a "what if" issue, for now, so we can gather things that we'd like to change at some point in time. A lot of changes to this project can be done without introducing any breaking changes and whenever we can do that, we try to stick to this approach.

Every actionable item (a one that we've agreed on) will be added to the corresponding milestone

cc
@mitchellhamilton
@Noviny
@zkochan
@arcanis I know that we were not able to converge on our way of doing things in the past but maybe this would be a good occasion to revisit our differences once again and take a look if they could be solved
@threepointone I know that you like the project so maybe you would have some quality input here
@ianstormtaylor I know that you had some quality suggestions in the past, you could resurface them here, or maybe even you have some more thoughts on the subject after using the project for a while

Prereleases need some attention. It's a high-value workflow but we've found across multiple projects that it's not ready for primetime.

@bennypowers

@bennypowers I agree that there are some issues with this but I don't have any strong solutions for this just yet. Could you list what issues you have encountered with them? Knowing the pain points would allow us to design a better solution

@Westbrook

Getting in and out of 'pre' mode has proven to be difficult.
We'd like to do things like:

maintain a long-lived prerelease branch
maintain parallel main and prerelease branches
publish pre-releases of single packages in a monorepo

The concept of "prerelease mode" has gotten in the way of those goals. From a user perspective, it would be much nicer to just pass --prerelease and --dist-tag options when actually running the publish step, rather than toggling some global state in the repo/branch

cc @Westbrook

^ +1 to making prereleases simpler. I would just like to cut a release at any time, and not have it be marked as latest. Very simply, can I simulate the experience of doing a full release, but without merging the pending release PR, and have it be published to alpha/canary/next. That would be super dope.

@threepointone

@threepointone you might be in for a treat, we already have "snapshot" releases.

This doesnt require any global state, just do smth like yarn changeset version --snapshot some_id_like_hash_or_pr_number_whatever_rly && yarn changeset publish --tag the_same_or_different_id. This still requires changeset files to be created as they are always an "intent of publishable change"). It can be seen in the wild here:
https://github.com/ianstormtaylor/slate/blob/9874ed704fecd989e1fed4114e4d4882f5d8aa76/.github/workflows/comment.yml#L58-L62
https://www.npmjs.com/package/slate-react?activeTab=versions

Ian here @ianstormtaylor actually doesn't add any additional tag to a snapshot release, so the published snapshots only have a date appended to them. Note that by default we use 0.0.0-* versions for those snapshots (for safety reasons) but you can opt-in to "calculated versions" with such a flag:
https://github.com/ianstormtaylor/slate/blob/9874ed704fecd989e1fed4114e4d4882f5d8aa76/.changeset/config.json#L14

This unlocks a whole set of use cases:

releasing on-demand, using a GitHub comment
releasing a dev channel from your trunk
releasing a daily canary releases
releasing preview releases per PR
and more

I’ve posted a new issue that could be interesting for some people who had contributed to the discussion here: #680

@Noviny

Getting in and out of 'pre' mode has proven to be difficult.

+1; "pre" mode is an unnatural ways of interacting.

May be provide params like --preid for version command (changeset version --preid alpha) is a alternative "concept" (not equivalent) of those pre commands

changeset pre enter alpha
changeset version
changeset pre exit

this likes --preid for npm and yarn, --override-prerelease-id for rush

cc: @Noviny @Andarist @bennypowers

I appreciate the RFC!

Better handling of private and ignored packages

Related: #436, changesets/bot#44

Currently, @changesets/cli and @changesets/bot try to bump any modified ignored or private packages by default. If they are not caught and removed before changeset version, versioning will fail. I hope to see better defaults regarding these packages, as it'll massively help external contributors who are less familiar with the repository.

Finer control of snapshot versions

Related: #573

We wish we had more control over version names on snapshot releases. changesets adds a timestamp as an identifier for each snapshot versions. But this can make versions really wordy if we put more information like hash to the version.

We wish we can control the format to make it more readable: 2.0.1-1fe6d0c, 2.0.1-2021.10.27, etc. I understand there are possible sorting problems, but this might be a good opportunity to revisit and understand the risk associated. Even if we find some risks, maybe we can have sensible defaults that we can override on our own risks.

I'll be glad to create any issues and contribute 👍

I just discovered this tool and it looks really cool!

Would support for polyglot monorepos be in scope for this project? Each language or build system would have a different way of storing its version so there would have to be some way to define projects in other languages.

I also recently started using nx, a build tool for polyglot repos. It maintains a dependency graph of all the projects inside it. If you decide to allow plugins to tell changeset about projects and their versions, a plugin could piggy back off of nx's dependency graph to determine what the next versions should be.

I just discovered this tool and it looks really cool!

Thanks :)

Would support for polyglot monorepos be in scope for this project? Each language or build system would have a different way of storing its version so there would have to be some way to define projects in other languages.

I'm open to this possibility but other maintainers are worried that this would make the code way more complicated and the gains could not be that great. As this tool is written in JS, it requires node etc and this might not be acceptable for people coming from projects written primarily in other languages. This might not be as big of an issue for polyglot repositories that already rely on JS but it's an important consideration.

That being said - I don't think this is off the table. It's just not super obvious how to implement this, how many people this would actually benefit and there is no clear plan for this. I'm also unsure if I'm able to figure this stuff out on my own any time soon - given that supporting JS ecosystem alone is already challenging and is consuming my, limited, time.

Better handling of private and ignored packages

I'll try to revisit this stuff when I have a chance. Thanks for bringing this up.

Finer control of snapshot versions

q: why does this matter? I mean - shouldn't you mostly access those snapshot versions through shorter and readable tags? Or just copy-paste them from one place to another? I'm not saying no - but I would really like to understand the motivation behind the request.

I'm open to this possibility but other maintainers are worried that this would make the code way more complicated and the gains could not be that great.

I can't really comment on the code complexity as I'm not familiar with the code base, but the gains would be for full stack monorepos that already use JS for the front end.

That being said - I don't think this is off the table. It's just not super obvious how to implement this, how many people this would actually benefit and there is no clear plan for this. I'm also unsure if I'm able to figure this stuff out on my own any time soon - given that supporting JS ecosystem alone is already challenging and is consuming my, limited, time.

My first thought as far as implementation goes is for the core logic of incrementing versions changes to be a pure function. Its inputs are the current versions, the dependency graph, and the changeset.

A plugin would be a module that exports two functions. One for scanning the workspace and returning a list of projects, and one for applying the version changes. The sticking point would be cross language dependencies. I can think of two options for this. One, add a config options. Two, require the user to write a bare-bones plugin that just returns their custom dependency configuration.

If no plugins are specified, it can default to a plugin that implements the current behavior.

As far as maintenance goes, if you can provide a stable API for the plugins then you can take a hands-off approach and leave the maintenance of individual plugins to the people that want them.

shouldn't you mostly access those snapshot versions through shorter and readable tags?

That's a good point.

For context, our repo deployed to @next on every merge to main, and one of our other projects needed to match specific commit. This was solved by above comment, but we were thinking that we could simplify versions to just 2.0.1-bcd1ea2 because it's all the information the project needed.

But as you brought up this isn't an actual blocker, and I agree, so I'll leave that to your discretion.

@Andarist

Can the 'pre' mode be simplified?

For Example

Execution

changeset add -pre beta

I think this is more convenient to use, if possible I can implement this function！
@Andarist

adding deno and jsr support would be great

adding deno and jsr support would be great

Yup, being able to publish to multiple package registries would be nice.

changeset publish is just doing npm publish currently, but it would be nice to extend that to have it perform jsr publish, or other private package registries aswell.

First off - this tool is great :)

I'd love to see some more tooling and specific docs / recommended workflows for managing and publishing prerelease candidates. This likely means dealing with releases and changesets within long lived branches, potentially multiple at the same time (might want to be working on the next major release and patch release at the same time), and keeping in mind the ability to easily release hotfixes to the main production branch.

I'd like to write Markdown content which would appear above the list of changesets in the next release. These "release notes" would let us add a brief, human-readable summary of our next version. "This release improves accessibility and adds new elements...", etc.

Hey! A small improvement I'd love to see in v3 would be clean dist files instead of the funny .cjs.mjs extensions

@oalexdoda Do you have any update on this? Do you know if anyone is working on adding bun support?

Support for bun.sh when using workspaces would be great. For some reason Bun uses workspace:* instead of workspace:^ and when you use that as the package manager, the workspace won't be replaced with the right version when you publish. Not sure if this can be addressed in a minor version or if it needs to go into v3. Stuck on pnpm at the moment because of it.

I'd love to see a --include parameter for version command.
#1672

Change default base branch from master to main. #675

Allow creating tags for private pacakge.json when running changeset tag. It means that privatePackages.tag should be true by default.

Defaultly enabling this will decrease the confusing issues, like #218.

Just want to +1 the suggestion for polyglot support. I love using changesets and would like to bring the release workflow into some of my Python projects as well. I've experimented with a pure Python repo, attempting to set up changesets/action via GitHub actions. It was almost seamless, though I had to incorporate a package.json for versioning and hack around the GH workflow.

As this tool is written in JS, it requires node etc and this might not be acceptable for people coming from projects written primarily in other languages.

Given that changesets are in markdown, they can be created and edited manually (or via a minimal language-specific CLIs – e.g., https://github.com/knope-dev/changesets). With changesets/actions, the core versioning and publishing logic could just be handled in CI by Node.js (regardless of whether the project is already using node).

I understand the concerns regarding code complexity and the need for Node, but I think the ability to configure changesets to update version field in different files other than package.json (i.e., pyproject.toml, Cargo.toml) could go a long way in enabling releases.

I just wanted to add support for polyglot support. Would love to use this in my python repos for a new job, and in my experience, python devs are not the most willing to install other tooling that is not python based.

I know pyright is written in .js but publishes a pypi package that forces node installation under the hood, so this might be as simple as bundling a pypi package?

GitHub immutable releases option prevents the upload of release artifacts once a release has been created in order to improve supply chain security.

At the moment, if you need to upload custom release artifacts I don't think it's possible to use Changesets with the immutable releases option turned on.

Being able to hook into the release creation process, or to specify a list of release artifacts for each package, would unlock immutable releases for libraries uploading custom release artifacts.

Is there already an ongoing discussion for making prereleases simpler / more granular?

We have the usecase over at Tiptap that we use fixed package versioning for almost all our packages but would like to take single packages out of that fixed versioning group & make beta/alpha releases for them before sending them off as stable. Currently that would mean we also have to go prerelease mode with all other packages as they often contain cross dependencies to one of our core packages.

Would love to participate in finding a solution for this problem.

closing in favor of #1945.

we will take a look at the requests in this thread for the v4 planning, as we're limiting the v3 scope to get it released in a reasonable amount of time!

Navigation Menu

Repository navigation

[Umbrella] Changesets v3 #665

Better handling of private and ignored packages

Finer control of snapshot versions

For Example

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Umbrella] Changesets v3 #665

Description

Activity

bennypowers commented on Nov 8, 2021

Andarist commented on Nov 8, 2021

bennypowers commented on Nov 8, 2021

threepointone commented on Nov 8, 2021

Andarist commented on Nov 8, 2021

Andarist commented on Nov 27, 2021

zthxxx commented on Nov 29, 2021

wlee221 commented on Dec 27, 2021

Better handling of private and ignored packages

Finer control of snapshot versions

Person-93 commented on Dec 28, 2021

Andarist commented on Dec 28, 2021

Andarist commented on Dec 28, 2021

Person-93 commented on Dec 28, 2021

wlee221 commented on Dec 29, 2021

zenotsai commented on Dec 31, 2021

For Example

10 remaining items

unional commented on Apr 1, 2024

maxpaj commented on Apr 13, 2024

theoephraim commented on Apr 24, 2024

bennypowers commented on Apr 24, 2024

GauBen commented on Dec 21, 2024

benallfree commented on Feb 18, 2025

DaveFz commented on May 13, 2025

zanminkian commented on May 28, 2025

zanminkian commented on Jun 4, 2025

hanseltime commented on Jul 24, 2025

uncrft commented on Sep 20, 2025

bdbch commented on Oct 7, 2025

beeequeue commented on Apr 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions