Perils of a monorepo: it's quite easy to cut a release while omitting a package. For example I can change CLI and runtime, publish the CLI package change, and forget to publish the runtime change. The CLI release may refer to code that doesn't exist.
That happened last weekend: a changeset was missing for a key package, which meant the package was not update on NPM, and the CLI was using an outdated package with code that didn't exist.
We cannot catch these errors in integration tests (although it's just the sort of thing you'd want them to catch) because the intergration tests run pre-release, before publishing to npm, from source. The version numbers don't matter.
The best defence I can think of against this sort of thing happening in the future is to:
a) Detect that a package had its source changed
b) Detect that the changed package has no changeset for (or version bump)
c) Alert users in the PR that there is no changeset.
Bear in mind that I'll occasionally merge code without a changeset. A type change, for example, or updating the readme. Something that doens't affect users and doens't warrant a release. So I want the option to disable the fail, or at least make this blocking.
This feature would also help encourage contributors to remember (or learn!) to include a changeset.
This might have to happen somewhere in the publish step, after versions are bumped. Depends a bit on what CLI capabilities we have.
A suggestion then for an action like this:
- Run on every open PR
- Detect a changed package without a changeset (I think the changeset CLI tells us this)
- Fails with a helpful error message
- Does not run if the "No changeset needed" label is on the PR
Perils of a monorepo: it's quite easy to cut a release while omitting a package. For example I can change CLI and runtime, publish the CLI package change, and forget to publish the runtime change. The CLI release may refer to code that doesn't exist.
That happened last weekend: a changeset was missing for a key package, which meant the package was not update on NPM, and the CLI was using an outdated package with code that didn't exist.
We cannot catch these errors in integration tests (although it's just the sort of thing you'd want them to catch) because the intergration tests run pre-release, before publishing to npm, from source. The version numbers don't matter.
The best defence I can think of against this sort of thing happening in the future is to:
a) Detect that a package had its source changed
b) Detect that the changed package has no changeset for (or version bump)
c) Alert users in the PR that there is no changeset.
Bear in mind that I'll occasionally merge code without a changeset. A type change, for example, or updating the readme. Something that doens't affect users and doens't warrant a release. So I want the option to disable the fail, or at least make this blocking.
This feature would also help encourage contributors to remember (or learn!) to include a changeset.
This might have to happen somewhere in the publish step, after versions are bumped. Depends a bit on what CLI capabilities we have.
A suggestion then for an action like this: