For an application, yes, commit the lock file. TL:DR; use “npm ci”, not “npm i”. This has several benefits; a) You know if a test fails, you broke something. N

For an application, yes, commit the lock file. TL:DR; use “npm ci”, not “npm i”. This has several benefits; a) You know if a test fails, you broke something. Not a bug caused by dep shift. b) Your team is using same versions of deps during dev (reduces “works on my computer” moments) c) Your builds are more reproducible. You can be more confident that you can exactly build say, last month’s version of the app and have it work the same way it did back then. Re: the noise problem, recommend using “npm ci” as the default and “npm i” only where you’re planning to update deps. This is less work than “freezing” stuff in package.json and also addresses the problem of transitive deps (the deps if your deps, which you would not really want to put in package.json anyway). Use npm audit to detect stuff that needs updating and treat periodic dep updates as a janitorial task. When you do updates, make a PR with just the dep updates (plus any changes needed for them to work) and make sure all the tests pass. You can mostly automate this. As a side note, the docs explicitly call out that the file is intended to be committed: https://docs.npmjs.com/files/package-lock.json https://docs.npmjs.com/files/package-lock.json