changesets / action

A tool to manage versioning and changelogs
with a focus on multi-package repositories

The changesets workflow is designed to help when people are making changes, all the way through to publishing. It lets contributors declare how their changes should be released, then we automate updating package versions, and changelogs, and publishing new versions of packages based on the provided information.

Changesets has a focus on solving these problems for multi-package repositories, and keeps packages that rely on each other within the multi-package repository up-to-date, as well as making it easy to make changes to groups of packages.

How do we do that?

A changeset is an intent to release a set of packages at particular semver bump types with a summary of the changes made.

The @changesets/cli package allows you to write changeset files as you make changes, then combine any number of changesets into a release, that flattens the bump-types into a single release per package, handles internal dependencies in a multi-package-repository, and updates changelogs, as well as release all updated packages from a mono-repository with one command.

How do I get started?

If you just want to jump in to using changesets, the Intro to using changesets and @changesets/cli docs are where you should head.

If you want a detailed explanation of the concepts behind changesets, or to understand how you would build on top of changesets, check out our detailed-explanation.

We also have a dictionary.

Integrating with CI

While changesets can be an entirely manual process, we recommend integrating it with how your CI works.

To check that PRs contain a changeset, we recommend using the changeset bot, or if you want to fail builds on a changesets failure, run yarn changeset status in CI.

To make releasing easier, you can use this changesets github action to automate creating versioning pull requests, and optionally publishing packages.

Documentation

• Intro to using changesets
• Detailed explanation
• Common questions
• Adding a changeset
• Automating changesets
• Checking for changesets
• Command line options
• Config file options
• Decisions
• Dictionary
• Fixed packages
• Linked packages
• Modifying changelog format
• Prereleases
• Problems publishing in monorepos
• Snapshot releases
• Versioning applications and other non-npm packages
• Experimental Options

Cool Projects already using Changesets for versioning and changelogs

• atlaskit
• emotion
• keystone
• react-select
• XState
• pnpm
• filbert-js
• tinyhttp
• Firebase Javascript SDK
• Formik
• MobX
• Nhost
• verdaccio
• Chakra UI
• Astro
• SvelteKit
• Hydrogen
• react-pdf
• GraphQL Code Generator
• GraphQL Yoga
• GraphQL-Mesh
• GraphiQL
• wagmi
• refine

Thanks/Inspiration

• bolt - Brought us a strong concept of how packages in a mono-repo should be able to interconnect, and provided the initial infrastructure to get inter-package information.
• Atlassian - The original idea/sponsor of the changesets code, and where many of the ideas and processes were fermented. It was originally implemented by the team behind atlaskit.
• lerna-semantic-release - put down many of the initial patterns around updating packages within a multi-package-repository, and started us thinking about how to manage dependent packages.
• Thinkmill - For sponsoring the focused open sourcing of this project, and the version two rearchitecture.

action's Issues

Create multiple PRs based off which packages are included in Changesets

On my team we have a mono-repo consisting of many packages that we use changesets to manage. We're also using changesets releases action to conglomerate version bumps in a single PR and publish to NPM when merged.

Some of our packages are dependent on others and require to be released in a specific order. Because of this, it'd be useful to be able to configure the release action so multiple PRs can be created depending on which versions are updated.

For example, there could be an option added where a dev could specify "create a Version Packages for package-abc PR when changeset for package-abc is detected" and a "create a Version Packages for all packages except package-abc PR which excludes package-abc but bundles all other bumps to other packages detected in changesets".

A feature such as this would give us more confidence and control in our release process.

Bump a major version with only patch changes

PR here: bytedance/bytemd#31

Commit using the env `GITHUB_TOKEN`

Hi!

Would it be possible to make the "Version Packages" commit using the GITHUB_TOKEN env var? I would like PR workflows to be triggered on this PR but since the commit is made by the github actions bot, workflows aren't triggered (because of Github's rule that "workflows can't trigger other workflows") unless I add a commit manually.

If this action used the GITHUB_TOKEN env var to commit the version bump, it would be possible to set the env var to a bot user token and the workflows would then be triggered on the PR (because the PR and commit come from a user account, not an action) without a manual step.

I looked around in the code to see if this was a straightforward change but it wasn't obvious to me. I'd be happy to make this change if it is doable and you think it's a worthwhile change but I wanted to get some feedback on the idea before diving in.

Don't run on forks

I saw this on Emotion, someone who had GitHub actions forked Emotion and a version PR was opened on their fork which doesn't seem like good behavior.

Incompatible with @changesets/cli v2.8.0

In @changesets/cli v2.8.0, the git tag format for single-package repositories has changed, which make this regular expression not longer working.

This causes two problems when using changesets/action with a single-package repositorie:

1. Can not create GitHub Release automatically.
2. The outputs (published and publishedPackages) from the Action don't contain correct package information.

How many action codebases?

Is it better to have one changesets GH action that's configurable with multiple actions, vs having different things for different tasks. The way this was initially set up, I thought we were going to be getting one package, but we've since divided. What's the reasons? Technical or philosophical?

Hypothesis: As a user, it would be good to be able to add the changesets github actions, the configure in one file what actions of it I use.

Downside: Shipping/loading unnecessary code + doing unnecessary work

Documented changes are overwritten on next update

I just noticed that when the "Version packages" PR gets updated, the previous entries get duplicated and/or overwritten.

For example:

I can try to look into it.

project's .npmrc not respected

Right now if you have an .npmrc at the project root that is not respected but rather the following piece of code just checks the .npmrc in the HOME directory

action/src/index.ts

Lines 44 to 53 in cd904b9

	let npmrcPath = `${process.env.HOME}/.npmrc`;
	if (fs.existsSync(npmrcPath)) {
	console.log("Found existing .npmrc file");
	} else {
	console.log("No .npmrc file found, creating one");
	fs.writeFileSync(
	npmrcPath,
	`//registry.npmjs.org/:_authToken=${process.env.NPM_TOKEN}`
	);
	}

Even the ideal flow for npm or any process is they check for .npmrc at the project root if not then they look for .npmrc in the HOME directory.

Tagging private packages on publish

I am working on a repository that has several packages:

• package_a (restricted -> deployed to gh packages)
• backage_b (dependent on package_a, private)

Package_b is deployed by another CI task, but I would like to tag it and possibly create a release based on the changesets/release. For example, if i make changes to package_b and create a changeset, the package_b version will be bumped. During the release step, changesets seems ignore this package because it is private and no tag is created.

I could create another step in my action to manually create a tag when the package_b version changes, but was wondering if I could have changesets handle this for me. I believe it would be essentially doing everything in the publish step without actually publishing the package to npm.

Questions:

• Is this something I should even be trying to do with changesets?
• Is there a way I can tag without publishing?

Appreciate any help or feedback!

Pushing to repo fails... possibly related to publishing to GPR?

Heya Guys, I have this little library within which I'm trying to implement changesets.

Initially I wanted to just process changesets, bump versions and publish new npm package when master changes, although now I realise that due to #77 it could be unfeasible?

In any case, I'm now just trying to get it working in the first place, so it goes through the pull request flow.

Variation on my situation is that my npm repo is the github package repository and I'm using pnpm and asdf (if that matters).

Error I'm getting when i merge the PR is

Run changesets/action@master
setting git user
/usr/bin/git config --global user.name "github-actions[bot]"
/usr/bin/git config --global user.email "github-actions[bot]@users.noreply.github.com"
setting GitHub credentials
/usr/bin/git checkout changeset-release/master
error: pathspec 'changeset-release/master' did not match any file(s) known to git
/usr/bin/git checkout -b changeset-release/master
Switched to a new branch 'changeset-release/master'
/usr/bin/git reset --hard a161afe0ea081204ad93acab4603305f476a04d4
HEAD is now at a161afe Implement Changesets Release Flow (#4)
/home/runner/.asdf/shims/node /home/runner/work/lootr/lootr/node_modules/.pnpm/@[email protected]/node_modules/@changesets/cli/bin.js version
🦋  All files have been updated and committed. You're ready to publish!
/usr/bin/git status --porcelain
/usr/bin/git push origin HEAD:changeset-release/master --force
remote: Permission to airtonix/lootr.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/airtonix/lootr/': The requested URL returned error: 403
Error: The process '/usr/bin/git' failed with exit code 128
    at a._setResult (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6638)
    at a.CheckComplete (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6068)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:5102)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
Error: The process '/usr/bin/git' failed with exit code 128

You can see it here : https://github.com/airtonix/lootr/runs/3391442726?check_suite_focus=true#step:7:26

my workflow file is here: https://github.com/airtonix/lootr/blob/8e004098ce7c8834769f0680db88f9f7f57c19d8/.github/workflows/release.yml

something to note, is that previous to bring in changesets, my pnpm publishing required the use of setting a NODE_AUTH_TOKEN due to actions/setup-node@v2 creating a .npmrc for me.

Deprecation notice for authentication via URL query parameters

Hi! Soon after setting this up I got an email from GitHub:

Hi @calebeby,

On August 14th, 2020 at 19:49 (UTC) your personal access token (____) using node-fetch/1.0 (+https://github.com/bitinn/node-fetch) was used as part of a query parameter to access an endpoint through the GitHub API:

https://api.github.com/graphql

Please use the Authorization HTTP header instead, as using the access_token query parameter is deprecated. If this token is being used by an app you don't have control over, be aware that it may stop working as a result of this deprecation.

Depending on your API usage, we'll be sending you this email reminder on a monthly basis for each token and User-Agent used in API calls made on your behalf.
Just one URL that was accessed with a token and User-Agent combination will be listed in the email reminder, not all.

Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates.

Thanks,
The GitHub Team

Can you switch out the authentication method so that this action still continues to work in the future?

Comment on issues and PRs that are fixed/included in releases to say something like "this fix for issue/this PR is included in x release"

Inspired by https://github.com/semantic-release/github

Not 100% sure about this because it could be spammy given that releases are batched in changesets but that problem doesn't really exist in semantic-release given that releases aren't batched

Skip createRelease

I'd like to avoid create GitHub releases, I have several packages in non production mode using alpha mode, every time I merge creates a lot of noise on my watchers. I've checked the code and I could not find any option, seems like goes as long publish the package.

I'm using it here https://github.com/verdaccio/verdaccio

It's related with #49

Base in your opinion, I'd be willing to work on it.

Don't overwrite ~/.npmrc

We publish to a private registry, and we have our .npmrc files initialized as needed to access those registries. Please don't blast away our configuration:

action/index.ts

Lines 88 to 91 in 2eb58c8

	fs.writeFileSync(
	`${process.env.HOME}/.npmrc`,
	`//registry.npmjs.org/:_authToken=${process.env.NPM_TOKEN}`
	);

Make the `upload_url` available as an action output

Hi there! 👋

It would be great to return the upload_url when a release is created (otherwise it could just be undefined), because it is often useful to be able to automatically upload artifacts. This is required with actions like https://github.com/actions/upload-release-asset.

screen

Defer NPM publish until PR merged

It appears that the changes PR-auto-submission & NPM publish happen simultaneously... there're some quirks that I'm struggling to figure out. I was wondering if anyone had advice for getting this workflow working properly:

1. make changes in feature branch, add changes to staging, trigger yarn changeset, push to feature branch.
2. feature branch action composes changes (since the last version from master). That generated changelog gets PRed to master.
3. merging the PR into master triggers build task(s), version bump(s), NPM publish(es), and then gets the release tags to be reflected in the repo's releases section.

Is this setup possible with this action?

app

Originally posted by @saq194 in #44

Latest commit on master breaking non-pnp Yarn installs

Commit bf4c612

Is breaking on our Yarn v1 (non-pnp) installs.

I switched the action back to use the previous commit and everything works fine again. (b3300fa)

The error I was getting is as follows:

Error: Cannot find module '@changesets/cli/package.json'
Require stack:
Error: Cannot find module '@changesets/cli/package.json'
Require stack:
- /home/runner/work/_actions/changesets/action/master/dist/index.js
- /home/runner/work/_actions/changesets/action/master/dist/index.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:797:15)
    at Function.Module._load (internal/modules/cjs/loader.js:690:27)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at f (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:293)
    at f (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:233)
    at p (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:544)
    at Object.w [as runVersion] (/home/runner/work/_actions/changesets/action/master/dist/index.js:906:3310)
    at async /home/runner/work/_actions/changesets/action/master/dist/index.js:908:1597 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/runner/work/_actions/changesets/action/master/dist/index.js'
  ]
}

Strange failures, not sure how to recover

A short while ago the action failed to make the PR as it is supposed to due to the following error:

nothing to commit, working tree clean
Error: The process '/usr/bin/git' failed with exit code 1
Error: The process '/usr/bin/git' failed with exit code 1

The CI run in question

I did have changeset files for this run (they are still there in master).

Now whenever I merge to master which runs the release steps that should generate a new PR, it fails in the same manner. I don't really know if it is the same issue I had originally or if I am stuck in a loop due to the original failure.

Any idea what could be causing this?

Pre-releases

Would it be possible to support pre-releases via this action, or is this already possible?

I know pre-releases are pretty complex with changesets but I wondered if the process could be simplified somewhat, I guess a string branching-naming strategy would be required to make it remotely reasonable.

I had a look for existing issues but I could not find anything. Is this something you would be interesting in supporting or is it already possible or perhaps too difficult?

app

Include pull request number in action output

👋🏻 Hi I would like to have the pull_number in the steps.changesets.outputs.pull_number output from the action step if steps.changesets.outputs.published == "false".

This is so I can have my action also post a status on the pull request after the changesets/action step runs.

action/src/run.ts

Lines 274 to 291 in aacbc22

	if (searchResult.data.items.length === 0) {
	console.log("creating pull request");
	await octokit.pulls.create({
	base: branch,
	head: versionBranch,
	title: finalPrTitle,
	body: await prBodyPromise,
	...github.context.repo,
	});
	} else {
	octokit.pulls.update({
	pull_number: searchResult.data.items[0].number,
	title: finalPrTitle,
	body: await prBodyPromise,
	...github.context.repo,
	});
	console.log("pull request found");
	}

Documentation suggesting `fetch-depth: 0` is out of date

The documentation for the action currently suggests this for the configuration:

This makes Actions fetch all Git history so that Changesets can generate changelogs with the correct commits

      fetch-depth: 0

This is no longer necessary: the tool will automatically deepen shallow clones as necessary since changesets/changesets#495.

Allow to configure the branch where the pull request is created

Hi, I would like to know if you are open to the idea of having the ability to change the branch that the release pull request is created via an option.

For the context, in my company we are using the git-flow process, all the code changes are merged into our develop branch, we create a release branch targeting master with all the changes and then once merged, merge master into our develop branch.
We would like to start using changeset into our flow but with this action the new release pr is always targeting our develop branch but we would like it to point to master.

I hope my use case is clear, if you think this change makes sense I can work on this :)

Is it possible to control the branch name of the PR

Hello,

Is there any way i can control the branch name this action creates for PR?
Current format changeset-release/target_branch breaks our branch name styling validations.

TIA

Any way to know if a publish occurred?

I'd like to send a Slack notification whenever a publish happens, but from what I can tell this action doesn't give me any way to determine if it just opened a PR or did a full publish. Maybe I'm missing something? If not, consider this a feature request!

When local `.npmrc` is found the action still says `No .npmrc file found, creating one`

Here's the repo where I have local .npmrc which is being considered but the changesets action still says.

No .npmrc file found, creating one

Here's the output message from running action

I got confused that it isn't picking up local my .npmrc even though it is. I think the messaging can be bit more contextual if it finds my local .npmrc. So I think we can change the messaging a bit.

Enabling custom commit message templates

This action can't be used in conjunction with varying commit linting configurations, as there's no way to customize the template from which the commit message is generated. I'm trying to use commitlint with a conventional commits config. I see that the action is writing the following commit messages...

when commiting for the sake of PR generation: CHANGESET: thick-mayflies-learn...
when commiting version bumps: Version Packages

This causes any commit-linting CI to fail with something along the following lines:

Side node: the placeholders (thick-mayflies-learn...) are awesome. Very tasteful.

Publish both to GPR and to NPM

I've correctly setup the Changesets Release Action to publish to GPR:

name: Release

on:
  push:
    branches:
      - master

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@master
        with:
          fetch-depth: 0
      - name: Setup Node.js
        uses: actions/setup-node@master
        with:
          node-version: 14
          registry-url: https://npm.pkg.github.com
      - name: Install dependencies
        run: npm i
      - name: Build packages
        run: npm run build
      - name: Create Release Pull Request or Publish to GPR/NPM
        uses: changesets/action@master
        with:
          publish: npx changeset publish
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

But I can't setup the Changesets Release Action to publish the packages both to GPR and to NPM. Is it possible in the latest version?

jjhh

Usage without pull request

Hey team,

I was just wondering if you had objections to a flag being passed which versioned direct on master (without going through the PR workflow).

The workflow I am thinking about has 2 jobs, the first simply runs changeset actions. If it versions any packages the second job will not run, the push would trigger master again which would release.

Otherwise I guess the manual way is to run changeset version, look for the warn that there are no packages to publish, then that is the flag to continue to next job?

Fail fast on CI when OTP for publish is detected

I've noticed that when OTP is set up for publish then the action can hang for 6h (GitHub timeout) without showing any logs. I think it would be possible to detect running on CI and failing fast in such a situation - with a descriptive error.

Tags corresponding to semver.

The docs for this action specify using @master. I've also noticed that the package.json version is stuck at 0.1.0 and is not being updated with new commits on master. Might we expect this repo to follow semver at some point in the future so it can be tagged accordingly with v1, v2, etc? That'd make me feel more comfortable that breaking changes would not be suddenly introduced in our workflows while not totally opting out of bug fixes and feature additions by using @[commit sha]. Thanks!

Action fails when NPM fetch fails

When running the action within github, I get this error:

🦋  info npm info @stacks/ui
🦋  info npm info @stacks/ui-core
🦋  info npm info @stacks/ui-theme
🦋  info npm info @stacks/ui-utils
error parsing json: 
🦋  error SyntaxError: Unexpected end of JSON input
🦋  error     at JSON.parse (<anonymous>)
🦋  error     at jsonParse (/home/runner/work/ui/ui/node_modules/@changesets/cli/dist/cli.cjs.dev.js:557:17)
🦋  error     at /home/runner/work/ui/ui/node_modules/@changesets/cli/dist/cli.cjs.dev.js:628:12
🦋  error     at processTicksAndRejections (node:internal/process/task_queues:93:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: The process '/usr/bin/yarn' failed with exit code 1
Error: The process '/usr/bin/yarn' failed with exit code 1

which is revealed to be this error when testing locally:

error an error occurred while publishing @stacks/ui-core: E402 402 Payment Required - PUT https://registry.npmjs.org/@stacks%2fui-core - You must sign up for private packages 

I'm not actually sure why it fails, because publishing that package by itself works fine.

It would be great if this error could be exposed more clearly from within the github actions UI.

Thanks for your work on this!

How can I run actions on "Version Packages" PR

Since Github workflows triggered from PRs do not run when a PR is created by Github actions, the required workflow to build and test before merging is not running when changeset bot creates a versioning PR. We tried to get around this with another action but weren't successful.

Curious what others are doing to get around this?

Our PR action

Custom Pull Request body

Right now, the PR body is either

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.

or

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.

I was wondering if we can accept a prBody via VersionOptions like we accept prTitle. I wanted to understand if there was any specific reason, this customization was restricted to title only. I'd be happy to raise a PR with these changes if the maintainers think this would be a good addition.

updating Version Packages PR uses GITHUB_TOKEN instead of PAT

Background

We have this running in master.yml

      - id: changesets
        uses: changesets/action@master
        with:
          publish: npm run release
        env:
          GITHUB_TOKEN: ${{ secrets.PAT_TOKEN }}
        ....

We also have a separate pull_request.yml that runs the usual lint and test status checks before it can be merged

When we used GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} before the PR action is not being triggered, so we had to use PAT. Now after a successful changeset merge it will create a new Version Packages PR and trigger the PR Action.

Problem

After a changeset merge with an existing Version Packages PR, the changes are pushed into the Version Packages PR correctly, however it is not triggering the action (git push is using GITHUB_TOKEN again)

Anyone found a way to have that git push use PAT as well?

Thanks

Setting GitHub credentials unnecessary?

Looks like the latest version of the actions/checkout action persists the GitHub credentials automatically, for usage by future job steps:

The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.

So was wondering whether these parts of your code are superfluous now?

https://github.com/changesets/action/blob/master/index.ts#L32-L50

Action updating closed PR instead of opening a new one

I've recently started noticing on one of my repos that this action is updating the most recent old/closed versioning PR, instead of opening a new one. Presumably something wonky with the search query defined here?

I can manually create a new PR based on the branch that the action created, and that works fine to merge and release the packages.

Adding label to PR

Hey. We'd like to be able to automatically add a label to the PR that gets created, is this possible somehow?

git pull error

I'm getting this error when the action runs:

 /usr/local/bin/pnpx changeset publish
🦋  info npm info @ianwalter/monorepo-app
🦋  info npm info @ianwalter/monorepo-hello
🦋  info npm info @ianwalter/monorepo-log
🦋  warn @ianwalter/monorepo-app is not being published because version 1.0.0 is already published on npm
🦋  warn @ianwalter/monorepo-hello is not being published because version 1.0.0 is already published on npm
🦋  warn @ianwalter/monorepo-log is not being published because version 1.1.0 is already published on npm
🦋  warn No unpublished packages to publish
/usr/bin/git pull origin master
fatal: Not a git repository (or any parent up to mount point /__w)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Error: The process '/usr/bin/git' failed with exit code 128
##[error]The process '/usr/bin/git' failed with exit code 128
    at a._setResult (/__w/_actions/changesets/action/master/dist/index.js:86:6638)
    at a.CheckComplete (/__w/_actions/changesets/action/master/dist/index.js:86:6068)
    at ChildProcess.<anonymous> (/__w/_actions/changesets/action/master/dist/index.js:86:5102)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Socket.<anonymous> (internal/child_process.js:430:11)
    at Socket.emit (events.js:210:5)
    at Pipe.<anonymous> (net.js:659:12)

You can see the entire log (and repo) here: https://github.com/ianwalter/monorepo-example/runs/860303546?check_suite_focus=true

I think the git commands shouldn't run in runPublish if changesetPublishOutput doesn't have a new tag ?

Integrated deployments

Hi everyone 👋

I'm curious if somebody could give me advice on how to configure the action with the deployment process.
The current process is simple. Every time on a push to master changesets/action creates/updates the PR, and when the PR merged, the packages are published to GPR.
However, the desired process is to have two deployments to DO:
The first deployment should be with the first step of the changesets/action - when PR is created, it deploys the particular changes to DO staging. I guess I could achieve it by creating a new workflow for the automatically generated PR.
The second one should deploy to DO production after changesets/action's PR is merged, and packages are published.

I'm not sure if it's the right approach in general. I'd like to hear if that's possible to achieve with the action, and any advice is welcome.

Move dependency updates to bottom unless major

For example see this - keystonejs/keystone#3605

there are tons of @renovate changes which fills the changelog with lot of dependency updates, this also clutters the view and not possible to see relevant changes

May I suggest that the changeset is created as such it will move all dependency update to bottom of the post. It would also be nice to add this as Table in monorepo packages and changes in dependency.

something like this (package version not actual)

package	Dependency	change type	contributor
@keystonejs/[email protected]	express@5	major	@renovate
@keystonejs/[email protected]	[email protected]	minor	@renovate
@keystonejs/[email protected]	[email protected].	patch	@renovate

Fails when using Yarn v2 + PnP

It looks like there's a line that explicitly references node_modules here: https://github.com/changesets/action/blob/master/src/run.ts#L186. When using Yarn PnP, this fails, since node_modules doesn't exist.

Error: Cannot find module '/home/runner/work/<pkg>/<pkg>/node_modules/@changesets/cli/package.json'
Require stack:
- /home/runner/work/_actions/changesets/action/master/dist/index.js
Require stack:
- /home/runner/work/_actions/changesets/action/master/dist/index.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:797:15)
    at Function.Module._load (internal/modules/cjs/loader.js:690:27)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at f (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:293)
    at f (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:233)
    at p (/home/runner/work/_actions/changesets/action/master/dist/index.js:1:544)
    at Object.w [as runVersion] (/home/runner/work/_actions/changesets/action/master/dist/index.js:906:3310)
    at async /home/runner/work/_actions/changesets/action/master/dist/index.js:908:1597 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/runner/work/_actions/changesets/action/master/dist/index.js'
  ]
}

Potential regression caused by #110

It seems that the latest changes merged from #110 are causing the release process to fail.

If I pin the GH action to the previous commit b98cec97583b917ff1dc6179dd4d230d3e439894 instead of changesets/action@master it works fine.

Not sure how the changes related to .npmrc are causing this issue 🤔. @Andarist any idea maybe?

Also, I noticed that there is something odd with the if-else logic. In my setup I do have the .npmrc file with the auth token but I see the message log Didn't find existing auth token for the npm registry in the user .npmrc file, creating one.

Let me know if I can help solving this. Thanks

Move createRelease logic to @changesets/cli?

It would be nice to be able to use the createRelease logic found here locally, perhaps as a separate release command in the CLI. So that you could do something like:

1. yarn changesets version
2. yarn changesets publish
3. GITHUB_TOKEN=xxx yarn changesets release or yarn changesets release --token xxx

My use case is testing local changes to @changesets/cli but I think it would be good to not have to rely on the GitHub actions, say if GitHub Actions is down but the API is not, or some other reason preventing the action from executing. You could fallback to running the process locally. What do you think?

Publishing of Yarn 2 workspaces won't remove version prefix

In our monorepo we use the native Yarn 2 workspace prefixes. For example, it looks like this:

{
  "dependencies": {
    "@easyfeedback/theme": "workspace:^1.1.1"
  },
}

If we now use yarn pack or yarn npm publish, the prefix is removed, as explained in the link above.
Unfortunately, this does not work when using the changesets/action.

My wokflow looks like this:

# ...

- name: Create Release Pull Request or Publish to GitHub packages
  uses: changesets/action@master
  with:
    commit: "Update version and deploy packages"
    title: "Update version and deploy packages"
    publish: yarn changeset publish
    version: yarn changeset version
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

# ...

Publish from `lerna` monorepo fails (Cannot read property 'includes' of undefined when publishing)

When attempting to publish from our lerna monorepo (https://github.com/lit/lit), we've been getting the following error from the publishing step:

2021-10-07T23:18:05.0477899Z 🦋  warn @lit-labs/motion is not being published because version 1.0.1 is already published on npm
2021-10-07T23:18:05.0479505Z 🦋  warn @lit-labs/react is not being published because version 1.0.1 is already published on npm
2021-10-07T23:18:05.0480890Z 🦋  warn @lit-labs/scoped-registry-mixin is not being published because version 1.0.0 is already published on npm
2021-10-07T23:18:05.0482246Z 🦋  warn @lit-labs/ssr is not being published because version 1.0.0 is already published on npm
2021-10-07T23:18:05.0483505Z 🦋  warn @lit-labs/ssr-client is not being published because version 1.0.0 is already published on npm
2021-10-07T23:18:05.0484742Z 🦋  warn @lit-labs/task is not being published because version 1.0.0 is already published on npm
2021-10-07T23:18:05.0485907Z 🦋  info lit is being published because our local version (2.0.1) has not been published on npm
2021-10-07T23:18:05.0487094Z 🦋  warn lit-element is not being published because version 3.0.1 is already published on npm
2021-10-07T23:18:05.0488279Z 🦋  warn lit-html is not being published because version 2.0.1 is already published on npm
2021-10-07T23:18:05.0489471Z 🦋  warn @lit/localize is not being published because version 0.11.0 is already published on npm
2021-10-07T23:18:05.0490707Z 🦋  warn @lit/localize-tools is not being published because version 0.4.0 is already published on npm
2021-10-07T23:18:05.0492155Z 🦋  warn @lit/reactive-element is not being published because version 1.0.1 is already published on npm
2021-10-07T23:18:05.0493426Z 🦋  warn @lit/ts-transformers is not being published because version 1.0.2 is already published on npm
2021-10-07T23:18:05.0502215Z 🦋  info Publishing "lit" at "2.0.1"
2021-10-07T23:18:06.7195484Z 🦋  success packages published successfully:
2021-10-07T23:18:06.7196962Z 🦋  [email protected]
2021-10-07T23:18:06.7197852Z 🦋  Creating git tag...
2021-10-07T23:18:06.7198758Z 🦋  New tag:  [email protected]
2021-10-07T23:18:06.7491906Z [command]/usr/bin/git push origin --tags
2021-10-07T23:18:07.6024711Z To https://github.com/lit/lit
2021-10-07T23:18:07.6026313Z  * [new tag]           [email protected] -> [email protected]
2021-10-07T23:18:07.6861499Z TypeError: Cannot read property 'includes' of undefined
2021-10-07T23:18:07.6862550Z     at f (/home/runner/work/_actions/changesets/action/master/dist/index.js:906:1660)
2021-10-07T23:18:07.6864403Z     at async Object.w [as runPublish] (/home/runner/work/_actions/changesets/action/master/dist/index.js:906:2582)
2021-10-07T23:18:07.6865487Z     at async /home/runner/work/_actions/changesets/action/master/dist/index.js:908:1443
2021-10-07T23:18:07.6873666Z ##[error]Cannot read property 'includes' of undefined
2021-10-07T23:18:07.7025596Z ##[debug]Node Action run completed with exit code 1
2021-10-07T23:18:07.7034160Z ##[debug]Finishing: Create Release Pull Request or Publish to npm

The correct package gets npm published and git tagged, but it looks like in the step that creates the github release fails with TypeError: Cannot read property 'includes' of undefined on L40 in the code below:

action/src/run.ts

Lines 36 to 42 in c291823

	await octokit.repos.createRelease({
	name: tagName,
	tag_name: tagName,
	body: changelogEntry.content,
	prerelease: pkg.packageJson.version.includes("-"),
	...github.context.repo,
	});

It looks like the root cause is that the version of @manypkg/get-packages used fails to classify our monorepo as a lerna type and tries to push a release for our root monorepo package (which has no version, causing the code above to fail).

Running 1.0.1 of @manypkg/get-packages in our monorepo returns root:

> (async () => console.log((await require('@manypkg/get-packages').getPackages(process.cwd())).tool))()
Promise { <pending> }
> root

Running 1.1.1 of @manypkg/get-packages correctly detects lerna, so I suspect just bumping that dependency should fix our issue:

> (async () => console.log((await require('@manypkg/get-packages').getPackages(process.cwd())).tool))()
Promise { <pending> }
> lerna

E404 Not Found - PUT for published packages

I'm using changesets github action to publish packages after running changesets version locally.

This is what I have in my github actions:

- name: Create Release Pull Request or Publish to npm
  id: changesets
  uses: changesets/action@master
  with:
    # This expects you to have a script called release which does a build for your packages and calls changeset publish
    publish: pnpm release
    commit: "chore: release"
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

this is what I get in actions logs:

🦋  error an error occurred while publishing @tinyhttp/ip-filter: E404 Not Found - PUT https://registry.npmjs.org/@tinyhttp%2fip-filter - Not found 
🦋  error 
🦋  error  '@tinyhttp/[email protected]' is not in the npm registry.
🦋  error You should bug the author to publish it (or use the name yourself!)
🦋  error 
🦋  error Note that you can also install from a
🦋  error tarball, folder, http url, or git url.
🦋  error an error occurred while publishing @tinyhttp/app: E404 Not Found - PUT https://registry.npmjs.org/@tinyhttp%2fapp - Not found 
🦋  error 
🦋  error  '@tinyhttp/[email protected]' is not in the npm registry.
🦋  error You should bug the author to publish it (or use the name yourself!)
🦋  error 
🦋  error Note that you can also install from a
🦋  error tarball, folder, http url, or git url.
🦋  error an error occurred while publishing @tinyhttp/unless: E404 Not Found - PUT https://registry.npmjs.org/@tinyhttp%2funless - Not found 
🦋  error 
🦋  error  '@tinyhttp/[email protected]' is not in the npm registry.
🦋  error You should bug the author to publish it (or use the name yourself!)
🦋  error 
🦋  error Note that you can also install from a
🦋  error tarball, folder, http url, or git url.
🦋  error packages failed to publish:
🦋  @tinyhttp/[email protected]
🦋  @tinyhttp/[email protected]
🦋  @tinyhttp/[email protected]
 ERROR  Command failed with exit code 1.
Error: The process '/home/runner/setup-pnpm/node_modules/.bin/pnpm' failed with exit code 1
    at a._setResult (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6638)
Error: The process '/home/runner/setup-pnpm/node_modules/.bin/pnpm' failed with exit code 1
    at a.CheckComplete (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6068)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:5102)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

When I run pnpm release locally, it runs just fine