Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Any reason for not committing the lock file?
See original GitHub issueHi!
This is not a bug issue, just a question. Is there any special reason not to be using a lock file? I guess it’d be package-lock.json, since the instructions mention using npm.
Issue Analytics
- State:
- Created 6 years ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Should I commit the yarn.lock file and what is it for?
Usually lock files (such as .ldb) are a means of limiting a resource to one process at a time to prevent the corruption...
Read more >Lockfiles should be committed on all projects | Yarn Blog
Without lockfiles it gets even more complicated: In applications or libraries, if there is no lockfile, you will have to check the dependencies...
Read more >When do you include the yarn.lock file to your git commit?
The entire reason for lock files is to replicate the environment anytime install is run. Checking it into a repo so everyone runs...
Read more >When not to use package-lock.json - DEV Community
Always commit your lock files, it speeds up CI builds because npm/composer wont have to locale the packages again since it caches the...
Read more >When Not to Use Lock Files with Node.js - Twilio
This is often the result of different underlying dependencies on the system of the person with the bug and your own system. As...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m seeing it’s around 340kb, is that a problem? I consider version pinning to be very important and would assume “install exactly the same dependencies” to be a very very attractive thing, even more considering it has no side effects.
In my experience it only actually changes when someone upgrades, adds or removes a dependency. But not in cases where you try something and later remove it. I may be wrong.
* I also speeds up the initial
npm install, but I guess that’s just a nice to have.I’m not really trying to convince you guys, I just found it really interesting that you didn’t commit the file.
Nice!