Do I commit the package-lock json file created by npm 5

Question

npm 5 was released today and one of the new features include deterministic installs with the creation of a package-lock json file   Is this file supposed to be kept in source control   I m assuming it s similar to yarn lock and composer lock  both of which are supposed to be kept in source control

User · Answer

I don t commit this file in my projects  What s the point     It s generated It s the cause of a SHA1 code integrity err in gitlab with gitlab-ci yml builds   Though it s true that I never use   in my package json for libs because I had bad experiences with it

User · Answer

To the people complaining about the noise when doing git diff   git diff --      exclude  package-lock json  --      exclude  yarn lock    What I did was use an alias   alias gd  git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines --      exclude  package-lock json  --      exclude  yarn lock     To ignore package-lock json in diffs for the entire repository  everyone using it   you can add this to  gitattributes   package-lock json binary yarn lock binary   This will result in diffs that show  Binary files a package-lock json and b package-lock json differ whenever the package lock file was changed  Additionally  some Git services  notably GitLab  but not GitHub  will also exclude these files  no more 10k lines changed   from the diffs when viewing online when doing this

User · Answer

Committing package-lock json to the source code version control means that the project will use a specific version of dependencies that may or may not match those defined in package json  while the  dependency has a specific version without any Caret     and Tilde     as you can see  that s mean the dependency will not be updated to the most recent version  and npm install will pick up the same version as well as we need it for our current version of Angular  Note   package-lock json highly recommended to commit it IF I added any Caret     and Tilde     to the dependency to be updated during the CI

User · Answer

Yes  it s a standard practice to commit package-lock json  The main reason for committing package-lock json is that everyone in the project is on the same package version  Pros   If you follow strict versioning and don t allow updating to major versions automatically to save yourself from backward-incompatible changes in third-party packages committing package-lock helps a lot  If you update a particular package  it gets updated in package-lock json and everyone using the repository gets updated to that particular version when they take the pull of your changes   Cons   It can make your pull requests look ugly     npm install won t make sure that everyone in the project is on the same package version  npm ci will help with this

User · Answer

Yes  package-lock json is intended to be checked into source control  If you re using npm 5   you may see this notice on the command line  created a lockfile as package-lock json  You should commit this file  According to npm help package-lock json   package-lock json is automatically generated for any operations where npm modifies either the node modules tree  or package json  It describes the exact tree that was generated  such that subsequent installs are able to generate identical trees  regardless of intermediate dependency updates  This file is intended to be committed into source repositories  and serves various purposes   Describe a single representation of a dependency tree such that teammates  deployments  and continuous integration are guaranteed to install exactly the same dependencies   Provide a facility for users to  quot time-travel quot  to previous states of node modules without having to commit the directory itself   To facilitate greater visibility of tree changes through readable source control diffs   And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages    One key detail about package-lock json is that it cannot be published  and it will be ignored if found in any place other than the toplevel package  It shares a format with npm-shrinkwrap json  which is essentially the same file  but allows publication  This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages  If both package-lock json and npm-shrinkwrap json are present in the root of a package  package-lock json will be completely ignored

User · Answer

Yes  the best practice is to check-in  YES  CHECK-IN   I agree that it will cause a lot of noise or conflict when seeing the diff  But the benefits are    guarantee exact same version of every package  This part is the most important when building in different environments at different times  You may use  1 2 3 in your package json  but how can u ensure each time npm install will pick up the same version in your dev machine and in the build server  especially those indirect dependency packages  Well  package-lock json will ensure that   With the help of npm ci which installs packages based on lock file  it improves the installation process  it helps with new audit feature npm audit fix  I think the audit feature is from npm version 6

User · Answer

Yes  you SHOULD    commit the package-lock json  use npm ci instead of npm install when building your applications both on your CI and your local development machine   The npm ci workflow requires the existence of a package-lock json     A big downside of npm install command is its unexpected behavior that it may mutate the package-lock json  whereas npm ci only uses the versions specified in the lockfile and produces an error   if the package-lock json and package json are out of sync if a package-lock json is missing    Hence  running npm install locally  esp  in larger teams with multiple developers  may lead to lots of conflicts within the package-lock json and developers to decide to completely delete the package-lock json instead   Yet there is a strong use-case for being able to trust that the project s dependencies resolve repeatably in a reliable way across different machines   From a package-lock json you get exactly that  a known-to-work state   In the past  I had projects without package-lock json   npm-shrinkwrap json   yarn lock files whose build would fail one day because a random dependency got a breaking update   Those issue are hard to resolve as you sometimes have to guess what the last working version was   If you want to add a new dependency  you still run npm install  dependency   If you want to upgrade  use either npm update  dependency  or npm install   dependendency   version  and commit the changed package-lock json   If an upgrade fails  you can revert to the last known working package-lock json     To quote npm doc      It is highly recommended you commit the generated package lock to   source control  this will allow anyone else on your team  your   deployments  your CI continuous integration  and anyone else who runs   npm install in your package source to get the exact same dependency   tree that you were developing on  Additionally  the diffs from these   changes are human-readable and will inform you of any changes npm has   made to your node modules  so you can notice if any transitive   dependencies were updated  hoisted  etc    And in regards to the difference between npm ci vs npm install         The project must have an existing package-lock json or    npm-shrinkwrap json    If dependencies in the package lock do not match    those in package json  npm ci will exit with an error  instead of    updating   the package lock     npm ci can only install entire projects at a time  individual dependencies cannot be added with this command    If a node modules is already present  it will be automatically removed before npm ci begins its install    It will never write to package json or any of the package-locks  installs are essentially frozen         Note  I posted a similar answer here

User · Answer

All answers say  quot YES quot  but that also depend of the project  the doc says   One key detail about package-lock json is that it cannot be published  and it will be ignored if found in any place other than the toplevel package   This mean that you don t need to publish on npm your package-lock json for dependency but you need to use package-lock json in your repo to lock the version of your test dependency  build dependencies    However  If your are using lerna for managing projects with multiple packages  you should put the package json only on the root of your repo  not in each subpackage are created with npm init  You will get something like that    git lerna json package json package-lock json         lt --- here packages a package json packages a lib index js packages b package json packages b lib index js

User · Answer

Yes  it s intended to be checked in  I want to suggest that it gets its own unique commit  We find that it adds a lot of noise to our diffs

User · Answer

Disable package-lock json globally  type the following in your terminal   npm config set package-lock false   this really work for me like magic

User · Answer

My use of npm is to generate minified uglified css js and to generate the javascript needed in pages served by a django application  In my applications  Javascript runs on the page to create animations  some times perform ajax calls  work within a VUE framework and or work with the css  If package-lock json has some overriding control over what is in package json  then it may be necessary that there is one version of this file  In my experience it either does not effect what is installed by npm install  or if it does  It has not to date adversely affected the applications I deploy to my knowledge  I don t use mongodb or other such applications that are traditionally thin client   I remove package-lock json from repo because npm install generates this file  and npm install is part of the deploy process on each server that runs the app  Version control of node and npm are done manually on each server  but I am careful that they are the same    When npm install is run on the server  it changes package-lock json  and if there are changes to a file that is recorded by the repo on the server  the next deploy WONT allow you to pull new changes from origin  That is you can t deploy because the pull will overwrite the changes that have been made to package-lock json    You can t even overwrite a locally generated package-lock json with what is on the repo  reset hard origin master   as npm will complain when ever you issue a command if the package-lock json does not reflect what is in node modules due to npm install  thus breaking the deploy  Now if this indicates that slightly different versions have been installed in node modules  once again that has never caused me problems   If node modules is not on your repo  and it should not be   then package-lock json should be ignored   If I am missing something  please correct me in the comments  but the point that versioning is taken from this file makes no sense  The file package json has version numbers in it  and I assume this file is the one used to build packages when npm install occurs  as when I remove it  npm install complains as follows   jason localhost introcart wagtail  rm package json jason localhost introcart wagtail  npm install npm WARN saveError ENOENT  no such file or directory  open   home jason webapps introcart devtools introcart wagtail package json    and the build fails  however when installing node modules or applying npm to build js css  no complaint is made if I remove package-lock json  jason localhost introcart wagtail  rm package-lock json  jason localhost introcart wagtail  npm run dev   gt  introcart 1 0 0 dev  home jason webapps introcart devtools introcart wagtail  gt  NODE ENV development webpack --progress --colors --watch --mode development   10  building 0 1 modules 1 active

User · Answer

Yes  you can commit this file  From the npm s official docs      package-lock json is automatically generated for any operations where npm modifies either the node modules tree  or package json  It describes the exact tree that was generated  such that subsequent installs are able to generate identical trees  regardless of intermediate dependency updates       This file is intended to be committed into source repositories

[node.js] Do I commit the package-lock.json file created by npm 5?

Examples related to node.js

Examples related to git

Examples related to npm

Examples related to version-control

Examples related to lockfile