-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why fixing deps version? #287
Comments
Explained here: #154 |
I have to argue about this opinion. What is said in the blog is fine, but it requires (said in blog):
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 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 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
|
Reping: The above reply is updated to clearly point out the incorrect part of the origin blog opinion. |
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. |
I summarized my thinking in a blog post. I understand folks may disagree. |
Is there any reason this package choose to lock an exact version in every deps?
markdownlint-cli2/package.json
Line 70 in 82c791e
E.g.: yaml release 2.4, while I can only upgrade to it by force overriding the version.
The text was updated successfully, but these errors were encountered: