I also agree that the package-lock.json should be committed. There are a few NPM commands that were released back in NPM 5.7.0+ that I feel would be worth using in our CI testing. These commands require either a package-lock.json or shrink-wrap.
Commands: npm ci npm cit => npm ci && npm t These commands are for continuous integration testing. https://docs.npmjs.com/cli/ci The downside is that the NPM version released with the latest Node 8 is 5.6.0 and does not have these commands. If we want to try and start using these commands, I recommend only on our Node 10 runs. I believe we should not upgrade the NPM version that comes with the latest install of Node 6 and 8. Users may not upgrade NPM. The best test case I feel would be to use what is bundled with the Node installation. - Bryan > On Aug 2, 2018, at 7:05, raphine...@gmail.com wrote: > > Yes, we should definitely commit package-lock.json. Gives reliable builds > and immutable releases. > > Conflicts during merges are common and a bit annoying, but easily resolved > if you know how. There even is a git merge hook for that [1] (more info on > this blog post [2]) > > [1]: https://www.npmjs.com/package/npm-merge-driver > [2]: > https://blog.npmjs.org/post/173240511455/the-new-npm-cli-a-year-in-review-or-what-you > > Jesse <purplecabb...@gmail.com> schrieb am Mi., 1. Aug. 2018, 23:50: > >> Yes, commit package-lock.json is the recommended practice, especially since >> we are not bundling. >> This ensures we all have the exact same version of all dependencies, which >> is the major benefit in my mind. >> If we just depend on package.json, some of the deeper dependency versions >> with wild card versions can differ based on when the developer ran npm i. >> >> The only disadvantage I see is: >> - I have gotten used to using autocomplete when I type `cat pac` to see the >> contents of package.json, now I have to type a little more. >> - If anyone uses yarn, this file is meaningless to them, and they might >> want us to commit yarn.lock also. >> >> >> >> >> >> @purplecabbage >> risingj.com >> >> On Wed, Aug 1, 2018 at 1:28 PM, Chris Brody <chris.br...@gmail.com> wrote: >> >>> I think we should start to commit package-lock.json in the next major >>> release but am not 100% sure. My understanding is that >>> package-lock.json mostly serves a couple major purposes: >>> * preserve the structure of node_modules cross-platform >>> * use SHA numbers to verify correct packages >>> >>> There seem to have been changes between npm@4 (??), npm@5, and npm@6, >>> as described in the following: >>> * https://github.com/npm/npm/issues/20434 (npm@5 vs npm@6) >>> * >> https://jpospisil.com/2017/06/02/understanding-lock-files-in-npm-5.html >>> >>> From what I read I think npm@5 & npm@6 would continue to follow the >>> semver rules for packages specified in package.json. >>> >>> Major advantages I can think of: >>> * better consistency for cross-platform development >>> * no need to regenerate package-lock.json for npm audit check >>> >>> But I can think of the following possible disadvantages to consider: >>> * not as easy to update dependencies, probably not possible to just >>> update dependencies by hand >>> * some additional "noise" in the git history, shouldn't be too bad though >>> * possibly major: in case people work on different dependency changes >>> in parallel and want to merge by git merge, rebase, or cherry-pick >>> dealing with the package-lock.json changes may not be so clean >>> >>> and a counter-point: >>> * https://www.codementor.io/johnkennedy/get-rid-of-that- >>> npm-package-lock-json-e0bj7ai42 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
