Why fixing deps version?

[Mister-Hope]

Is there any reason this package choose to lock an exact version in every deps?

markdownlint-cli2/package.json

Line 70 in 82c791e

"yaml": "2.3.4"

E.g.: yaml release 2.4, while I can only upgrade to it by force overriding the version.

[DavidAnson]

Explained here: #154

[Mister-Hope]

I have to argue about this opinion.

What is said in the blog is fine, but it requires (said in blog):

Automate some process to make sure you remain up-to-date.

Also the blog opinion is obviously too "aggressive". It's true that developers make release unworkable updates upstream, so that this affect any packages requiring it, but by requiring other packages, it means that you trust the package behavior (Obviously you haven't check the codes of every dependency and the whole dependency trees in you project). So, it's fair to say that your project can still have potential bugs and mysterious codes from upstream.

The correct behavior is actually trying to require any popular library which has capable developers, and try not require any deps that is no longer actively maintained (a lot of issues remain unhandled) or some unpopular ones. One of the basics (especially in node.js where you probably get 1k+ deps on just a medium size project), is to trust your deps chain, and believe even there are bugs long upstream, they will be fixed very soon. So that unless your package is strong related with security, you should try to use ^x.x.x as possible.

---

Another thing is that it has almost no benefit to lock the version. The whole community is not doing the same thing. Even if you lock a dep A, its dependencies update may still break that version of dep A.

One of the biggest disadvantages is that locking to a version or refuse to update major version in time, will cause duplicate version of the package. The reason I opened this issue, is that I have a tool to track my deps number, and mark any duplicate version of same deps with same major, them yaml are, when I install projects like eslint which also requires yaml, I will have the latest 2.4.1 in my project, yet I have to install an outdated deps 2.3.4 because of this package. It's exacerbating the "tons of deps" problem.

If every packages are doing like the blog says, you will likely to have at least 50% more deps installed in your project, because when a level 5 dep (also being required severl times on deps tree) release a new version, it will take a long time for any deps requiring it to update, and there will be a lot of duplicated versions of packages like this installed while it keeps releasing new version. Each packages may have its own release cycle, so the users at end of the deps tree has no chance to see a constant version requirement.

---

So, the fine solution is that, either stop locking any verion, or

Automate some process to make sure you remain up-to-date.

[Mister-Hope]

Reping: The above reply is updated to clearly point out the incorrect part of the origin blog opinion.

[DavidAnson]

I understand the points you make and agree the community does not pin. However, it's my time that gets wasted when another project breaks their code in a patch release. And I've wasted that time on many occasions. I can't change everyone's behavior, but I can control my own and pinning is a safer practice. Correctness is more important to me than the chance of avoiding duplicated dependencies. Without pinning, users wind up running untested code and problems show up unexpectedly for them. With pinning, problems only show up during version updates and can be avoided by skipping the update. People who disagree with this approach and are willing to troubleshoot can choose to force version overrides via npm or yarn.

[DavidAnson]

I summarized my thinking in a blog post. I understand folks may disagree.

https://dlaa.me/blog/post/versionpinning