Omit private packages from lists of changed and unchanged packages offered by the CLI when running `yarn changeset`

Affected Packages

• @changesets/cli

Problem

The list of packages offered by yarn changeset includes private packages (i.e. packages with private: true in package.json). In projects with broad contribution, contributors may not be aware that only packages that get published should be included in changesets, and include those private packages. This creates noise for maintainers, who have to explain the issue and ask the contributor to fix the changeset.

Proposed solution

If a package is marked as private, it shouldn’t be included in the lists of changed and unchanged packages offered by the CLI. This behavior could be behind an optional flag if there are workflows where including private packages in this list makes sense.

[Andarist]

My only concern is that people may still want to have a version field for private package to be able to reference them inside a monorepo. When using yarn, workspace:* protocol helps, but I am not sure it works with NPM, which means people need to specify some version to reference package they need.

There is also file: protocol and it’s supported by npm. So this could potentially still be used there.

But I struggle to find any practical use case when 2 private packages inside a monorepo refer to each other.

You may still need to reference a private package in dev dependencies of a public package - and referencing a private package from a private package doesn’t look that different to me, or am I missing something? 🤔

Do I understand correctly, that adjusting the behavior to omit all the packages without a version field applies not only to changeset add command but to other commands as well?

Yes, this would have to be taken into account in the system as a whole. It’s hard for me list all the exact places right now though - but hopefully this should limit itself to just a couple of places.

Does Changesets even work when version field is absent? If it does not, skipping packages without version absolutely makes sense and my concern above can be ignored.

I’ve recently opened a PR to fill the missing version ( https://github.com/changesets/changesets/pull/705 ) and this has prompted the discussion that maybe instead of doing that we should ignore private package without a version. The version will still be required for publishable packages though - and we might want to throw when a version is missing in such a package.

[bhovhannes]

@Andarist I have implement changes locally, however, I think that will be a major change because people will no longer see private packages in the list displayed by CLI which can be a pain for them if they are creating changesets for private packages as well.
To avoid breaking changes I can work on introducing a new config option - skipPrivatePackages which will be false by default, fully preserving current behavior of the CLI. When skipPrivatePackages will be set to true private packages will be totally omitted by CLI.
There are multiple ways new config option can be added, so I’ll be grateful to hear maintainers opinion on this.

We don’t use changesets now, but we have a use case for generating changelog for private packages. We are moving to micro-frontends and each micro-frontend is a npm package, which never gets published. Instead we just deploy content of dist folder to S3 and update import-map in html. We even want to prohibit users from publishing micro-frontends to npm, so we have private: true set in package.json.

BTW, thank you for nice code in the repo. During implementing changes I realized that I do not feel like I am working in a “foreign” repo, which was awesome!