Yarn workspaces doesnt detect mine how to#
Yarn workspaces doesnt detect mine update#
Yarn workspaces doesnt detect mine zip#

It should work the first time, but once you commit those package versions, running `npx babel ` may break depending on what is in your package-lock.json file, and when. breaks! And you won't exactly know when until it does and you have to delete your package-lock.json file. The example of adding JSX to an existing website. Take React.js's 'Add React to a Website' article for example. 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. Now it seems that there will forever be a Yarn version inside that project.

I often need to work with a project, which has a big monorepo and chose to bundle its version of Yarn with that. It seems more standard and safer than Yarn ever did, so I never bothered with upgrading Yarn. 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. To me it was outrageous, that a tool used by so many could have such flaws. 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. 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. 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. * Sometimes a package is broken because they don't specify peerDependencies properly (which is a security & reliability issue), so you have to add to a config file (surprising first time, easy from then on). * in the beginning it was hard to step into dependencies. then they need a little help resolving packages * I don't care about package compatibility

Yarn workspaces doesnt detect mine update#

* I don't have to chase people to update when a lib we use has a vuln

Yarn workspaces doesnt detect mine how to#

* I don't have to teach other people how to look after their packages (because it 'just works') * I don't get breakage because I switched branches * I don't worry that the server is running something different to the dev machine Things I haven't thought about or done since switching to yarn 2:

Yarn itself is saved into the repo, so the only external dependency is nodejs.

Yarn workspaces doesnt detect mine zip#

I've had a small number of packages have issues with the zip format, which is solved by setting unplugged (very well documented).Ī user clones the repo and they are done. Dependencies can have conflicting dependent packages. yarn/cache folder (equiv of node_modules) to git (via git-lfs). That is because I have not gone against the default of 0-config repos, that is saving the. Since I migrated everything to yarn 2 its been a breeze, my other contributors have been able to completely forget about it (as it just works) and I've been able to assert that everything that works today will work in six months and two years. I run about ~30 JS repos, ~10 of them monorepos. I'm grateful to the Yarn project for pushing NPM in the right direction, and wish it and its remaining users all the success in the world, but I no longer see an urgent need in the ecosystem for Yarn to exist and would no longer recommend it by default for any greenfield project. Performance and reliability have been notably better in my experience (keeping in mind that my baseline for comparison is a release of Yarn from two years ago). Luckily, the stable release of NPM 7 arrived just in time for us to switch over with minimal hassle. At that point, it was untenable for us to continue relying on a broken, unmaintained tool for such a critical function. Meanwhile, the old release of Yarn 1.x that I'd pinned in order to work around a blocker regression (v1.21.1) was starting to show its age, and eventually became unusable after a third-party package update triggered another hidden blocker bug in that release (which, IIRC, the team had elected not to fix because only 1.x was affected). Yarn >=2 is probably fine for what it is, but I wasn't prepared to invest resources into rearchitecting how we handle dependencies for nebulous (or possibly negative) benefit. NPM 7 is fantastic, and feels like a worthy successor to Yarn 1. My experience with Yarn 2 was switching to NPM 7.