How to handle package-lock.json?

[johnbrett]

In npm5 the package-lock.json has been added.

When you npm install this file is created automatically, and when you npm version patch etc, this file is will be committed unless removed.

Have we any stance on whether hapi ecosystem modules should add/ignore/remove these, considering maintainers will see this message:

Will these affect how shrinkwrap will work?

[geek]

hapi is ignoring the new lock file https://github.com/hapijs/hapi/blob/master/.gitignore#L17

I think this is a good move, but there is a bug in npm5 around using version when the package-lock.json is in .gitignore, so you are forced to manually delete the file if you want to run that command.

Until most of the major issues in npm5 are addressed around the package-lock.json we should avoid committing it.

[johnbrett]

Thanks @geek! Is the plan to start committing it when the issues around npm5 are resolved, or we'll discuss that when the time comes?

[geek]

I am not sure what other people's plans are, but if having the lock file improves performance with cloning/installing the repo then I'd like to start committing it.

[johnbrett]

Makes sense, thanks again 👍

[ljharb]

You can also add package-lock=false to your .npmrc

[Marsup]

I'm personally against so I'll keep ignoring it.

[nlf]

i don't see it as any different than npm-shrinkwrap.json. we don't include it for libraries now (except for hapi itself) so why would we start?

to prevent npm from creating the package-lock.json automatically, we can add a .npmrc file to each repo with package-lock=false as its contents. i think that's a better approach than adding it to .gitignore since it helps make sure that the developer isn't running tests with locked dependencies that won't be locked when the library is published.

[ljharb]

I'd recommend both - I believe only apps should have lock files, and you both want to prevent people from accidentally creating one and also from accidentally committing one.

[devinivy]

package-lock.json is different than a shrinkwrap because it does not ship with the npm package, and it is superseded by any shrinkwraps. Because hapi has a shrinkwrap, it will simply be ignored by npm anyway.

[AdriVanHoudt]

It does indeed not make too much sense to have it for non-apps.
It does not get bundled on publish. CI will always test the latest of everything which mirrors the install behaviour of a user.
It would only lock for the developers which might cause a mismatch with what gets installed by a user or CI.

[csrl]

So what's the conclusion on this? add it to .gitignore? add a repo specific .npmrc? I'm going to reopen the issue so we can get the best practice agreed u[pon and captured.

Related, I scanned the contrib docs, and I don't see anything the captures our use of .npmignore .gitignore best practices. There's been various issues raised and resolved that we've all generally aligned on, but it doesn't seem those decisions made it into the docs?

[ljharb]

@csrl i'd suggest something like ljharb/qs@f0c1480 or tape-testing/tape@df48bfa

[hueniverse]

.gitignore + local config based on your preferences.

[ljharb]

(if I'm understanding your comment) I don't think "preferences" should figure into it for individual developers; every user of the repo should be forced to use, or to not use, a given lockfile, for consistency. (Obv repo collab's preferences should decide what repo users do)

[hueniverse]

Point is, never commit your lock file to git. If it is in the ignore file, it will never get committed. I don't care if you generate one locally or not.

[eliasmelgaco]

Create a file named .npmrc and put in your body

package-lock=false

hope this helps

[dominykas]

Create a file named .npmrc and put in your body
package-lock=false

Do note that this will not only disable the creation of package-lock, but it will also ignore the npm-shrinkwrap if present, so adding it into a global (~/.npmrc) rather than a per-repo file may be undesirable.

[wambete]

package-lock.json is supposed to facilitate flawless operation in webpage development and Mobile Apps especially where minor changes are made, like bug fixes, and point to major changes where there is a version upgrade....I think. Check this link on how to react a package.json file for subsequent version / iterations https://docs.npmjs.com/creating-a-package-json-file

[Marsup]

Lock file is useful for apps, never for libraries.

[Nargonath]

Doesn't it have value for libs as well to speed up installs on CI using npm ci? The command requires a package-lock to work.

[ljharb]

Why do installs need to be sped up on libs? What libs have a large enough dep tree that that makes a difference? and isn’t that really a problem with npm ci, not with not having a lockfile?

[Nargonath]

@ljharb Good point.