-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Regenerate package-lock #7417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@dplewis @davimacedo What's your take on this? |
We use to manually update it every time we create a new release. Maybe we could add this step to the ci process. Updating it at each release would be probably enough, right? |
Yes, I think so. Adding to the CI is a good idea. |
should be closed @mtrezza ? |
Thanks for opening this issue!
|
I'm not sure. It's an open topic. If we regenerate package-lock we'll miss security upgrades of sub-dependencies that snyk and dependabot did over time. If we don't regenerate package-lock, there will probably be other outdated sub-dependencies. |
oh i see, may be a monthly CI with automated PR to try a package lock regen @mtrezza |
Maybe, but not sure how many snyk PRs that will reset and snyk will re-open again if we do that monthly. Maybe quarterly? I guess we'd have to try out. |
New Feature / Enhancement Checklist
Current Limitation
It is currently undefined if and when
package-lock.json
should be completely regenerated.The current approach seems to allow (partial) updates when:
The limitations of that seem to be:
The effect seem to be that sub-dependencies of packages that use range operators do not get updated. This is especially true for packages with low release frequency.
From a package deployment perspective,
package-lock.json
should be touched with care as it ensures a consistent dependency tree across deployments. However, from a package development perspective, regularly rebuildingpackage-lock.json
seems a necessity due to the common use of range operators in dependencies.Suggestion
Regularly completely regenerate
package-lock.json
in a dedicated PR. Possibly automated.The text was updated successfully, but these errors were encountered: