Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Using (or not) package-lock.json

See original GitHub issue

We’ve begun piecemeal removing package-lock.json, with @brianleroux recently citing the following link re. lockfile (non-)use:

My own conclusions: package-lock.json provides no benefit in published packages, but remains necessary for deterministic deployments of actual Architect project app repos. So official Architect packages could stand to shed package-lock.json, while https://github.com/architect-examples should keep their lockfiles.

That said, in a world constantly creeping entropy, I like to fend off instability with whatever determinism I can find. Some alternative ideas:

Swap out package-lock.json for npm-shrinkwrap.json – theoretically solves the issue of npm ignoring the lockfile for published modules adding the determinism of a lockfile to our packages, but we still pay a penalty in dep updating noise, git pack size, etc., and it’s officially warned against for libraries
- Further: I’m not sure this is a meaningful real-world issue? Architect has been downloaded and used quite a bit, and I’m unaware of >= second-order dependency mismatches presenting issues to us or our users
Dependency version pinning – we started pinning first-level dependencies in @architect/architect 6.0.11 last September; I like this approach, and I’d suggest every official production Architect package should only be allowed to have version-pinned dependencies (devDependencies are fine to be ranges)

Thoughts?

Issue Analytics

State:
Created 4 years ago
Reactions:1
Comments:6 (5 by maintainers)

Top GitHub Comments

3reactions

ryanblockcommented, Mar 3, 2020

After giving this some further consideration, I’m thinking we’re going to start rolling out with the following .npmrc to all packages:

package-lock=false
save-prefix=~

This will ensure all packages’ core deps are patch-only (no minors); Dependabot should help manage everything else, and majors and minors will be ensured to only be rolled up into proper Architect releases.

Otherwise: devdeps are still fine to use ^, and package-lock.json will no longer be checked in (of course).

Big ups to my old buddy @celly for his thoughts on this as well!

1reaction

ryanblockcommented, Mar 22, 2020

Will be retired in 6.2.5, hopefully shipping today!

Top Results From Across the Web

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

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

package-lock.json - in GIT or not? - DEV Community ‍ ‍

One solution for this problem is to commit the node_modules folder to GIT, which includes all of the code your application uses. This...

Do I really need package-lock.json file? - Medium

The command npm instal installs all packages defined in package.json file and their dependencies, in the node_modules folder, creating it if ...

package-lock.json - npm 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 ......

Why you should use package-lock.json - LogRocket Blog

Make sure you don't change package-lock.json directly. That's being handled automatically by NPM. It reflects changes made to package.json ...