Warn on npm publish when pinning to patch versions of packages.

[ChALkeR]

With #8617, another nice thing to have apart from #8339 would be dependencies versions checks.

A warning when one pins to a patch version of a package that has a major version greater than 0 would solve a lot of problems in the ecosystem.

The last condition is crucial, no one would want a warning just because the package version is 0.0.1.

Also a notice could be introduced when one uses npm-shrinkwrap.json, but that is less critical, because that one is less common and people who use npm-shrinkwrap.json probably know what they are doing (while people who pin to patch versions generally don't).

[othiym23]

While npm (and node-semver) are pretty opinionated about what constitutes good semver usage (and thus the existence of ~ and ^, and various versions of npm defaulting to saving dependencies prefixed with one or the other), this isn't an area where it makes sense for npm-the-tool to have an opinion. People have varied (and strong) feelings about the best way to do versioning when you publish packages or deploy applications (see this tweet from this morning, which basically advocates the completely opposite position as this issue's), and npm is most powerful in this regard when it's most flexible. (--save-exact is another example of how this plays out in practice.)

This is definitely something that would be useful in an opinionated package linter, rather than included in npm by default. As such, I'm going to close this issue. I am curious, though – what's the use case you see for this feature? What problems is it meant to address?

[ChALkeR]

@othiym23 The author of that tweet is very far from the real world.

Let me describe the current situation.

There are a lot of npm modules, more than 150k atm. The dependency chains for the modules are long enough, a situation when module dependencies have 10 levels is rather common. And each module has multiple dependencies, of course. The main idea is that there are very many links in those 150k modules.

Now imagine that you have anything of the following:

1. A module that has an error in it, so it breaks on some occasions.
2. A module that has an error in it, so it stops working with a new platform version.
3. A module that uses removed or changed platform API, so it stops working with a new platform version.
4. A module that uses removed or changed non-platform API, so it just stops working.
5. A module with a security vulnerability.

If all goes well, the module author updates the module and fixes things, but that's just the tip of the iceberg. The solution is not complete until every strict dependency is succeedingly (from bottom to top) bumped in every dependency chain that has that module. Some modules could even need updating several times, because they could be part of several of those chains.

A more detailed example: if there is one module that uses unsupported functionality of the platform, you can't just remove or fix that part of the platform and update that module, even with feature detection. You have to make sure that no modules fix an old version of the module in question that does not support the new platform. And after you make sure of that, you have to make sure that no modules fix an old version of the modules that got updated in the previous sentence. And after you make sure of that, you have to make sure that no modules fix an old version of the modules that got updated in the previous sentence. And … (repeat several times, until you do not care anymore).

The sad part of this is that we already have the solution for all of the above issues. And it's semantic versioning.
Well, it would be the solution if everyone used that properly.

BTW, that tweet you mentioned completely disregards semver. If you strictly fix your versions, there is completely no difference between semver and a simple integer as the only version indicator.