@jcbhmr I wonder if we should still merge this.

I came to the realisation: adding "publish": false, to the "np" configuration in package.json actually might be enough in our case.

• You can make a release if you want by manually creating a tag & release on Github. Manually writing the release notes.
• I can make a release if I want just as always: npm run release which runs np to do some minor safety checks (no changed files, correct branch, run tests) then it still creates the Github Release for me automatically in the browser with the automatically added release notes like i'm used to.

The fact that it won't publish from my local machine means the github action now succeeds.
Also made sure tests are ran again before the npm publish, just in case.

So I think that covers my automation wishes? Not sure if we need to force PR authors to bump their own package in this case. : )

What do you think?

I still think warning (it doesn't block the merge) with a ❌ since you didn't bump the version is a Good Idea™. This is like a very basic version of "semantic release" workflow that doesn't incur any overhead like requiring labels on PRs like "major" and doesn't require "feat(thing): did thing"-style commit conventions. It's just a light "you should change the package.json version if you touch src/ stuff" workflow

TLDR: I think that this is still a good thing to merge because it stops silly "forgor version bump 😜" commits AND forces PR authors to consciously think "what kind of change is this?"