issue/5051 - incorrect peer dependencies on v1 lockfile upgrade
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
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:
- Arborist to do this itself
- Not have to run reify twice to get this behavior
?
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:
- Arborist to do this itself
- 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.