4 ms·
To be completely fair, it isn't exactly drop-in. There's new commands for a bunch of things, mainly around adding new packages locally and globally. I led the y
by mynameisvlad 9y ago
To be completely fair, it isn't exactly drop-in. There's new commands for a bunch of things, mainly around adding new packages locally and globally. I led the yarn switch effort on my direct team and had people coming to me weeks after asking how to do X because of the different commands.
- rmrfrmrf 9y agoI suspected that someone would mention this, but the fact of the matter is both systems are mostly interoperable. The switch from npm to yarn would be nothing like migrating from Gulp + Browserify to Webpack. To switch to yarn, I printed out a one-page cheat sheet and taped it to my wall. I’ve had one blunder in the time I’ve used it (misunderstanding what `yarn upgrade` did x_x), but it was easily reverted.
- Silhouette 9y agoI think you're making TeMPOraL's point, though. Even in this relatively close case, it's not a zero-overhead transition. There are some changes. There are some new behaviours. You still need to know which things really work exactly the same and where the differences come from even if those differences are only minor. You always need due diligence about whether a new tool is reliable, future-proof, trustworthy, etc. And that's all after finding out about the new tool and deciding this one is actually worth looking into. Multiply all of that by the absurd degree of over-dependence and over-engineering in the JS ecosystem, and it's entirely fair to question whether the constant nagging overheads are worthwhile.
- rmrfrmrf 9y agoRight, and that non-zero overhead is part of being a software developer. It’s also laughable that npm is accused of being a hack and yarn is accused of being over-engineered.