how to ignore private packages?

[priley86]

building off of #15

can you provide an arg or some sort of publish config option to ignore private packages in the changelog? The suggest fix here will not work for our repo.

I'd like some sort of option or config to do this and ignore our private root packages from our CHANGELOG. It does not seem that command.bootstrap.ignore from lerna.json is an option either.

[Turbo87]

I don't think there is currently an option to ignore packages like that, but feel free to come up with a PR :)

[pladaria]

@Turbo87 is there any other way to ignore packages from versioning?

[Turbo87]

as I said, not until someone builds one 😅

[Marcosld]

Opened a PR for ignoring packages from versioning and publishing here https://github.com/lerna/lerna/pull/2507

[m-mayank]

Lerna(v3.21.0) does not publishes the private packages if we use --no-private flag in publish command.

Reference: https://github.com/lerna/lerna/tree/master/commands/version#--no-private

[ntucker]

Lerna(v3.21.0) does not publishes the private packages if we use --no-private flag in publish command.

Reference: https://github.com/lerna/lerna/tree/master/commands/version#--no-private

However that also makes it not bump the package versions of published packages in the private packages, which will remove semlinks and thus break the entire repo if the version no longer matches.

i.e., in private package A, referencing ^5.0.0, with a public package bump of B to 6.0.0 - this will BREAK the monorepo. There is no scenario where this is not a bug since lerna is managing the packages of both private and public packages.

[maribethb]

The previous comment is also a problem for us.

For context, we use "private: true" in some packages which are "coming soon": they aren't ready to be published yet, but they will be soon. In the meantime, we still want them to be updated whenever their dependencies change -- just don't bump their version number. Otherwise when we do eventually publish them, rather than starting at v1.0.0, they are first published at 1.0.32 or some other arbitrary number representing how many times we published its dependencies before the new package was ready. Or, if we use the --no-private flag, we risk using out-of-date dependencies in the new package, potentially even missing major updates.