Replies: 1 comment
-
Thank you for opening this @nyandika You shared this nice article about pinning exact dependency versions. The article talks about two ways of preventing the problems that arise from pinning, but I find the second approach controversial. What I find controversialRemoving the default caret ( The number one reason I get for this kind of pinning is to protect against the breakage of the app by rogue packages. This rarely works since all the sub-dependencies are still free to update. Also chances that a sub-dependency breaks the app increases with this kind of pinning. I think the lock file already does a good job of locking the packages we depend on including sub-dependencies. The lock file gives us "pinning" even without removing the caret. I believe the npm team put in enough thought when switching to using the caret as the default and I do not see a very convincing enough reason against this default. While this is my position, I know that there are a few packages on npm that do not strictly follow semver, or sometimes we have cases where different packages clash with each other and in these cases, I would also recommend saving an exact version of this package once such a problem is detected. What I find controversial is choosing an all-or-nothing approach to this where we totally opt out of all the benefits of the caret in getting us automatic patches and backward compatible features in our codebase. What I agree with and how I personally handle itI personally agree with pinning dependencies using a This is from my personal experience and I am open and willing to learn about different opinions on this as we agree on how to deal with dependencies in the project. |
Beta Was this translation helpful? Give feedback.
-
This is borne from the discussion here
This is a general discussion to collect views on it to shape dependency management in the repo
Beta Was this translation helpful? Give feedback.
All reactions