--ci should be the default, both locally and on CI servers

Just a friendly note: packages should not be published with lock files.

This defeats the purpose of semver version ranges, because then if a dependency’s dependencies are locked, ranges can not be satisfied, which breaks the workings of semver.

npm publish ignores package-lock.json files and will not publish them to the registry. The docs mention

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.

but they don’t go into much more detail.

Let me explain why packages should not rely on lock files.

Imagine that you test your package always using npm ci with lock files. Great, now you are certain your package works with specific versions of dependencies.

In practice, and because package-lock.json is never published to npmjs.com, users receive versions of packages that satisfy version ranges of dependencies.

If an in-range version of some package breaks your user’s experience because it breaks your package, you’ll never know because you’ve always tested with npm ci and assumed the versions of dependencies would never change. If you use the regular npm install while developing and testing packages, you’ll be able to catch breaking changes that would affect your users and be able to remedy the problem for them sooner.

Another problem is, if every single dependency of you package were to be version pinned, this would increase the chances of causing problems with dependencies that expect their export to be a singleton. As an example, the popular react library expects its APIs to be a singleton. When a component instance created from one version of React is passed to another version of React, it can self destruct 💥. When versions are locked in a dependency you don’t control, then it becomes difficult to manage when such issue arise (I’ve experienced it).

For these reasons use of lock files is not recommended for most packages.

Lock files are great for applications, or for CLI programs which are in effect applications, but not for most packages. The generic rule is that “top most” packages may usually have lock files, but this is only a guideline and there may be exceptions. Generally speaking, the majority of packages should not use lock files.

---

Contrary to this article, I believe instead we should all strive to test our code better and prevent in-range breaking changes.

Greenkeeper found that about 15% of in-range updates introduce breaking changes.

Now that GitHub Actions are out, it may become easier for authors to add CI and testing to their libraries. Let’s strive to make the ecosystem and conventions better.

Conclusion

As such, I believe that the behavior of --no-ci should be the default, because that is inline with npm publish functionality, and people should be testing for that use case, unless they use Lerna to manage an application and application-specific dependencies.

---

P.S. I opened this issue because when I tried running lerna bootstrap in a CI environment for the first time, npm ci failed.

[intafon]

Yes, that seems to actually be the case.

lerna bootstrap --loglevel debug shows that npm install is used.

export CI=true; lerna bootstrap --loglevel debug shows that bootstrap uses npm ci when CI env variable is set (true as a value works, not sure what it should be, haven’t messed with github actions). lerna bootstrap --ci --loglevel debug also uses npm ci.

Thanks for the tip!

Note: I confirmed, via testing and as noted in https://github.com/lerna/lerna/blob/master/doc/hoist.md, that invoking either of lerna bootstrap --hoist --ci --loglevel debug or export CI=true; lerna bootstrap --hoist --loglevel debug does NOT use npm ci, but instead uses npm install.

[github-actions[bot]]

Hi Folks 👋

You will have seen in our message above that we at Nrwl are working really hard to bring the lerna repo up to date with what matters most to its community in June 2022.

As previously stated in that message, because we have not heard from the original author of this issue within the last 14 days, we are now automatically closing it.

If any users, including the original author, are still impacted by this issue then we still want to hear from you!

All we ask is that you first update to the latest lerna (5.1.4 at the time of writing) to make sure it is still reproducible, and then fill out one of our new issue templates, providing all the requested details which apply to your situation:

https://github.com/lerna/lerna/issues/new/choose

Many thanks again! 🙏

---

P.S. Over and above getting to grips with the repo, we have also been hard at work launching a new website, resolving all vulnerabilities, merging exciting new features and reigniting community PR contributions! 🚀

You can read our recent blog post to learn more about what we’ve been up to: https://blog.nrwl.io/lerna-5-1-new-website-new-guides-new-lerna-example-repo-distributed-caching-support-and-speed-64d66410bec7