© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
We've been developing with package-lock.json tracked in the repo for several months now and I finally have some clarity on this. I've come around to the idea of (mostly) not using it.
The main question we have to ask: in what contexts do we encourage updating npm dependencies and when should we lock it down?
In contexts where we encourage it, we should remove package-lock.json and prevent the file from being created via configuration -- not just ignore it. I think this should be the default behavior.
In contexts where it's useful to have a manifest of the exact dependencies used, we should track package-lock.json and restrict installation procedures to using "npm install" (which reads package-lock.json) and not "npm update", which ignores package-lock.json for depencency resolution.
I suggest we do this for release tag branches (e.g. tags/rel_3_2_3). That way every build of tags/rel_3_2_3 uses the same dependencies.
My proposal is this:
1. Disable package-lock.json in Ang and AngJS via .npmrc files within each directory
2. Do not add it to .gitignore since it won't be created anyway (unless we want it).
2. Remove the existing package-lock.json files from the repository.
3. Modify the build scripts to allow for the generation of package-lock.json files during release building so that it's added to tag-release branches only.
Here's a branch to implement #1 and #2. Will wait for feedback on #3.
https:/