[Umbrella] Changesets v3

[Andarist]

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

[bennypowers]

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

[Andarist]

@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

[bennypowers]

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

[threepointone]

^ +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.

[Andarist]

@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

[Andarist]

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

[zthxxx]

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

[wlee221]

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 👍

[Person-93]

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.

[Andarist]

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.

[Andarist]

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.

[Person-93]

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.

[wlee221]

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.

[zenotsai]

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

[Phiphi1996]

Code

[airtonix]

Better support for monorepos that release groups of artifacts at different schedules.

In my recent hunt for better release/changelog management, I've started circling around several tools/concepts:

• changelog generation driving the version management
• version changes when we generate an artifact to be inserted into our release process.

Right now, Changesets only works well for library monorepos. It kinda works ok for monorepos that contain apps, but it falls over when you have a QA pipeline and you then need to follow a git-flow process.

---

"Keep a changelog" and Changesets (if you use it in combination with the changesets/action ) both have a similar feature: unreleased changes.

• changesets/action handles this by rolling everything that's changed into one single PR. merging this PR causes everything to be released.
• Keep A Changelog while having no official implementation, instead declares unreleased items as entries in each packages CHANGELOG.md, when you choose to process this section it gets converted to a version.

---

My current thought process is that in order to support a git-flow process (with release branches, hotfixes to those branches, release branches being pushed to staging, production targets) is that i'd need to move away from changesets and instead adopt something like "Keep a changelog".

The problem is that we'd be moving back to the idea that PR titles are now our changelog entries. While not the worst, it isn't as flexible as changesets i guess?

If the changeset action could support configuration that allows multiple unique release pullrequests (driven by configuration, maybe a list of globs) then we could automate the creation of our release/appname-version branches by merging a pull request for a certain app.

[waldronmatt]

Support for conventional commits via a plugin would be a game changer for people/teams using it or coming from a semantic release background.

[benmccann]

I would like to see CJS build dropped at least from the CLI: #587 (comment). This could arguably be done before v3 as it wouldn't be considered a breaking change if you assume people are only interacting with the CLI via the CLI and not importing it as a library.

[airtonix]

I would like to see CJS build dropped at least from the CLI: #587 (comment). This could arguably be done before v3 as it wouldn't be considered a breaking change if you assume people are only interacting with the CLI via the CLI and not importing it as a library.

That would be an incorrect assumption. 👍🏻

[manzt]

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.

[oalexdoda]

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.

[ptim]

I'd love to see --dry-run included (may not require v3?)

#614

[bennypowers]

esm sources please.

if i load up @changesets/read in a module project, i have to do this:

import read from '@changesets/read'
const cSs = await read.default(process.cwd());

[jlmeister]

My org has a monorepo with a use case for managing multiple major versions of some modules. The issue is the modules are listed by name when using add as well as in the changeset files, and in this case, some packages will undoubtedly have identical names.

I see you use package.json name from the return from @manypkg/getpackages. They also include the relative path of the module in the Package class. Perhaps including a new config option for packageNamingStrategy, where the default is name but can also be path? I'm happy to dig in and provide a PR.

[unional]

adding deno and jsr support would be great

[maxpaj]

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.

[theoephraim]

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.

[bennypowers]

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.