Describe the user story
When developing libraries, having a lock file can prevent the detection of issues with newer packages, that ultimately will be pulled by dependents.
But maybe still locking dev-dependencies can be useful. This would be up to the developer?
Describe the solution you'd like
In a perfect world, we should be able to choose what dependencies to lock: all, dev, none.
all would primarily be used by applications (no dependents).dev and none could be used for libraries (that have dependents).It can be a field in .yarnrc.yml, maybe lock: (all|dev|none) ?
Berry should be able to replace already installed dependencies by a new one if available (and not locked) when doing yarn install. It can be annoying to delete the whole node_modules folder every time. Edit: or should a dev use it would upgrade dev dependencies as well, which we might not want.yarn upgrade in this case?
Describe the drawbacks of your solution
Maybe slower installs? I can live with that as long as it does what I want. Only impacts people disabling the lockfile.
Describe alternatives you've considered
Running yarn upgrade often. But this pollutes the commit history in some way, and might lead to merge conflicts on the lockfile. Even though old yarn was able to resolve those conflicts, it is still annoying to land in that state.
Additional context
N/A
This isn't something we'll implement. More details here.
So the alternative for an active project would be to regularly manually run yarn upgrade and push it upstream every so often?
Yep. To make that easier, various bots exist that automatically run upgrades periodically and open PRs to run the tests against the new set of dependencies (Renovate / Dependabot).
I tend to get whatever latest and resolve issue if there is any. If they don't want to implement it, whenever I saw that file, I do:
rm -rf yarn.lock
Most helpful comment
This isn't something we'll implement. More details here.