Skip to content
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

issue/5051 - incorrect peer dependencies on v1 lockfile upgrade #7118

Open
wants to merge 2 commits into
base: latest
Choose a base branch
from

Conversation

siemhesda
Copy link
Contributor

Npm does not capture conflicting dependencies with old lockfiles (npm@6) . On the first install from an old lockfile, the lockfile gets upgraded but the install command captures the old lockfile during the install. This update checks for old lockfiles and re reifies to ensure the updated lockfile is used during the second reification.

References

closes #5051

@siemhesda siemhesda requested a review from a team as a code owner January 3, 2024 18:24
@siemhesda siemhesda changed the title fix(install): re run reify if lockfile is old issue/5051 - incorrect peer dependencies on v1 lockfile upgrade Jan 3, 2024
@wraithgar
Copy link
Member

I don't know that solution is the right one. It seems a little overwrought. "do the install twice based on new state Arborist is tracking for this single situation." feels like a pretty heavy-handed approach. Is there no better way for:

  1. Arborist to do this itself
  2. Not have to run reify twice to get this behavior

?

@siemhesda
Copy link
Contributor Author

I don't know that solution is the right one. It seems a little overwrought. "do the install twice based on new state Arborist is tracking for this single situation." feels like a pretty heavy-handed approach. Is there no better way for:

  1. Arborist to do this itself
  2. Not have to run reify twice to get this behavior

?

The first instinct was to do it within the arborist but the challenge is that it does not wait for the lockfile to be updated before proceeding with execution. Hence doing it on the install when everything is already done. Also the shrinkwrap, which I think plays part in this, is not asynchronous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] npm 8 allows incorrect peer dependencies when upgrading a v1 lockfile to v2.
2 participants