I had issues with Yarn 1, when it came to concurrently managing its own cache, when I had packages, which have dependencies to private git repos, which could be referenced using multiple ways of writing their URLs. In such cases one had to manually make sure, that the order of installed packages is exactly right, otherwise the cache gets into problems and errors would appear. Afaik that issue never got resolved, except perhaps by accident in a newer version of Yarn, but no explicit treatment of admission of the issue.
To me it was outrageous, that a tool used by so many could have such flaws. I stayed with npm, which also has the advantage of storing a more precise lock file than Yarn and I never had the same kind of issues as I had with Yarn. It seems more standard and safer than Yarn ever did, so I never bothered with upgrading Yarn.
I often need to work with a project, which has a big monorepo and chose to bundle its version of Yarn with that. Now it seems that there will forever be a Yarn version inside that project.
I have not noticed that much of a speed difference between npm and Yarn once things are cached and I value safety and correctness more than speed anyway, so that has not been a reason for me to try and make the switch either.
To me it was outrageous, that a tool used by so many could have such flaws. I stayed with npm, which also has the advantage of storing a more precise lock file than Yarn and I never had the same kind of issues as I had with Yarn. It seems more standard and safer than Yarn ever did, so I never bothered with upgrading Yarn.
I often need to work with a project, which has a big monorepo and chose to bundle its version of Yarn with that. Now it seems that there will forever be a Yarn version inside that project.
I have not noticed that much of a speed difference between npm and Yarn once things are cached and I value safety and correctness more than speed anyway, so that has not been a reason for me to try and make the switch either.