Add support for `ignored` config

I’ve discussed this briefly with @mitchellhamilton yesterday and he has validated my idea and asked me to create an issue about it for further discussion.

Problem

It seems useful to be able to opt-out of auto-publishing sometimes. Most notably when adding a new package (but working on it gradually) or working on a new version of a particular package without entering pre mode for it (might be overkill).

Currently, there is no such way, "private": true works the same way as other packages - it just aint being published to npm, but it’s a subject to changelog/tag generation and dependencies bumps. At first it has been suggested that this use case has already been discussed here, but actually it hasn’t. This one is not about changing how changesets manage dependencies permanently (a very core logic) but rather just about “muting” certain packages temporarily.

Proposed solution

Introduce ignored list - it would simply skip its entries in @changesets/assemble-release-plan.

Things to take care of so a cohesive experience can be provided

• dependencies should still be bumped (written to package.json), but it wouldn’t trigger a new release
• changesets for ignored packages should be kept and shouldn’t affect the release flow
• we should throw for “mixed” changesets (containing ignored and not ignored packages)

[emmatown]

A builtin config has an important (IMHO) advantage over the ability to just manipulate a release plan - it can be implemented in a safer manner, with some opinions about how such feature should work ofc, so it still maybe wouldn’t be able to cover all the use cases, but I think that an opinionated builtin solution would be good as this use case here doesn’t seem to be overly rare.

I agree with this.

I think that if we can get away with not allowing people to manipulate release plans, we should do it.

[Andarist]

It’s unclear to me whether it’s better to add ignore as config, or add the ability for a user to write something like the above (with probably a guide to doing it and base function) that they can plug in.

That’s definitely a hard decision to make 😉 A builtin config has an important (IMHO) advantage over the ability to just manipulate a release plan - it can be implemented in a safer manner, with some opinions about how such feature should work ofc, so it still maybe wouldn’t be able to cover all the use cases, but I think that an opinionated builtin solution would be good as this use case here doesn’t seem to be overly rare.

That being said - I think it would be extremely useful to expose some hooks as you have described, so people could manipulate stuff according to their needs.