You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I develop a web application where we pin our direct dependencies to exact versions. From time to time it would seem prudent to update the indirect/transitive dependencies. This can be done by deleting yarn.lock and running yarn install. However a colleague has suggested that yarn up -R '*' is somehow safer, though I don't understand his reasoning. I guess it could be safer in the case that a security fix has set a package resolution to a version outside of the semver range, which would be lost by regenerating the lock file, though I am not sure that dependabot will actually create a PR that sets a version outside of semver.
I tried the two methods just now on separate branches and compared the yarn.lock diff between them. The two were mostly identical, but regenerating the file did get rid of a few more older duplicates of the same package that yarn up did not.
Update: Tried running yarn dedupe after yarn up -R '*' and found the diff between the two branches reduced to only differences in some of the package versions (the regenerated lock file had newer versions)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I develop a web application where we pin our direct dependencies to exact versions. From time to time it would seem prudent to update the indirect/transitive dependencies. This can be done by deleting
yarn.lock
and runningyarn install
. However a colleague has suggested thatyarn up -R '*'
is somehow safer, though I don't understand his reasoning. I guess it could be safer in the case that a security fix has set a package resolution to a version outside of the semver range, which would be lost by regenerating the lock file, though I am not sure that dependabot will actually create a PR that sets a version outside of semver.I tried the two methods just now on separate branches and compared the
yarn.lock
diff between them. The two were mostly identical, but regenerating the file did get rid of a few more older duplicates of the same package thatyarn up
did not.Update: Tried running
yarn dedupe
afteryarn up -R '*'
and found the diff between the two branches reduced to only differences in some of the package versions (the regenerated lock file had newer versions)Beta Was this translation helpful? Give feedback.
All reactions