Regenerate yarn lockfile

[outoftime]

The yarn lockfile is path-dependent on the particular order of package installations and upgrades that we do over time, leading to things like unnecessarily duplicate packages, sub-dependencies that are out of date, etc. Apparently the move is to just delete it and re-generate it with yarn install. As long as all direct dependencies are already at their semver latest, this doesn’t have any effect on the packages we interact with directly.

[meg2208]

@outoftime in my experience, you should never need to make a PR like this if yarn is used properly. Instead of adding new dependencies by manually updating the package.json, they should always be added using yarn add <dependency>@<version> and that will update the package.json and yarn.lock for you. That is how I have done it at work and that is how I did it in other PRs for this project.

Perhaps you already knew that, but just wanted to throw in my two cents!

[outoftime]

@meg2208 hmm, that hasn’t been my experience—I exclusively use yarn add and yarn upgrade to manage dependencies (never directly edit package.json) but the situation with the sub dependencies (dependencies of dependencies) still gradually deteriorates. This leads to an increasing list of yarn deduplication warnings that are not particularly actionable other than by a PR like this one.

This issue with yarn is widely discussed and there is a longstanding issue that is still open in the project. I do notice in that issue (which I had not specifically come across before) there is mention of a yarn-tools package whose primary purpose is to deal with duplicates that have accumulated in the lockfile. I will try that next time it’s time to do an upgrade sweep.

In the context of the above you still think I’m missing something, though, please do elaborate!

[meg2208]

I see what you mean, so yarn doesn't fully support updating transitive dependencies (sub dependencies). As you mentioned yarn-tools fix-duplicates command does accomplish this, but it seems like that should be part of yarn natively, but is not (yet).

Interestingly, I have definitely had this problem with other programming languages too, and this is a problem that Java 9 Modules tried to solve by basically letting you only export transitive dependencies if you explicitly state that you want to do that.