I expect these usability issues will be ironed out in future versions. I’m not saying you should disable package-lock.json, but doing so has enabled me to keep my workflow with npm v5, as I used with npm v4. If you are interested in diving deeper into the issue, there’s a good discussion going on in the npm issue tracker (#16866). Others are hitting this situation as well. The lock file can easily get out of date if package-lock.json exists before the install or if a co-worker forgets to update package-lock.json before pushing to a repository. The lock file is created every time a dependency is installed ( npm install lodash) or npm install is run in npm v5. I’ve run into multiple instances where dependencies do not install as expected due to package-lock.json existing. A -flag parameter that is at the end of the command will be given the value of true. A - argument tells the cli parser to stop reading flags. rm -f package-lock.json & \ npm install lodash -save & \ rm -f package-lock.json But why? npm gets its configuration values from the following sources, sorted by priority: Command Line Flags Putting -foo bar on the command line sets the foo configuration parameter to 'bar'. I recommend one of the above approaches instead of this. npm config set package-lock false Installing without creating the lock (one time) If you want completely disable package-lock.json creation on your machine, simply set the config globally. gitignore Disabling package-lock.json Globally *nix users may use: echo 'package-lock=false' >. npmrc at the root of the project and add package-lock=false to it. To tell npm not to create a package-lock.jsonlock file for your current project, create a file called. Lock via Disabling package-lock.json Locally
0 kommentar(er)
