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 > > > > >
