Bugfixes, Breaking Changes, and Correct vs. Pragmatic

Bugfixes change and correct behavior of the npm CLI. Often times these changes are entirely positive, enabling more use cases, unblocking developers, providing consistency, and providing more security. But sometimes, the fixes correct subtle errors that the users may not have been previously aware of. Even worse, some users may rely on incorrect, insecure, inconsistent, future-error causing behavior.

Bugfixes that break workflows are very common. Users often depend on behavior that is fundamentally incorrect. They may not know or care about the the subtleties of how things were broken, and how it affects our userbase. Most bugfixes are not considered breaking changes.

The npm CLI team has to consider how many users might be effected by fixing a bug. We have very limited information to make an informed decision. Usually, a bugfix "breaks" a very limited number of users, but sometimes, as is the case with this npm ci validation, there are a significant number of users that are effected.

In considering bugfixes like this, we have to balance correct behavior, security, number of users effected by broken behavior, and the potential number of users effected by the corrected behavior. Sometimes we have opted to enshrine the bug with documentation, punt until the next major release, or find a configuration solution. However, we almost always lean toward correct behavior, especially when security or multiple issues are involved.