Replies: 3 comments 3 replies
-
|
Totally agree, i've always used it in my projects without issue. I generally take some time every once in a while to update deps or i just throw in dependabot |
Beta Was this translation helpful? Give feedback.
-
|
We could make a nightly CI which updates lockfiles |
Beta Was this translation helpful? Give feedback.
-
|
It might become a pain when conflicts will occur especially that we have many packages in one repo and it looks like those files are huge 250k+ already added in your draft. I'm not either for it or against yet, might read more about all possible cons and prons for that. Would not rush with this yet. |
Beta Was this translation helpful? Give feedback.
-
|
This is something I have done on other teams. There are automated tools to fix merge conflicts in package-lock files, including one official one from npm. Also, you can always just delete the package-lock file and run install again to regenerate it to fix the conflicts. |
Beta Was this translation helpful? Give feedback.
-
|
Have decided to move forward with this and labeled the associated PR as ready for reviews |
Beta Was this translation helpful? Give feedback.
-
|
after first "touch" with this during release slowly starting to regret it :/. it is polluting the changes, hard to spot what changed, resolving conflicts etc.. It will speed up build but it is slowing down human |
Beta Was this translation helpful? Give feedback.
-
I created a draft PR around this #1829
Checking in lockfiles results in MUCH faster CI builds. It also enables local developers a chance to install dependencies in a fraction of the time when there is a problem which requires reinstalling dependencies (which happens often).
I know some people have concerns that checking in lockfiles prevents us from getting the latest dependencies in CI until the package-lock is updated, but I believe these issues are well mitigated by using the dependency updating bot. I would encourage everyone to read the following blog post if they are unsure. It is old and written to specifically target yarn, but nothing it says is not also applicable to npm: https://classic.yarnpkg.com/blog/2016/11/24/lockfiles-for-all
We also have extremely few non-dev dependencies, especially compared to to the massive number of dev dependencies we have. This affords fewer chances for a bad dependency to break users.
Beta Was this translation helpful? Give feedback.
All reactions