OpenFn / OpenFn/kit

In CI, warn (fail?) if a package is changed but doesn't have a changeset

Open
#1,476 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
21
Forks
23
Avg merge
1d 22h
Merged PRs (30d)
17

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the repository's CI workflows and the changeset CLI or publish step referenced in the issue. Trace how an open PR's changed packages and labels are exposed, then make the check report missing changesets, allow the "No changeset needed" label, and verify the behavior on PRs.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.