Proč vývojáři přechází z npm na Yarn

Why Developers Are Moving to Yarn - CircleCI

Potential problems with npm

• nested dependencies (fixed in npm 3)
• serial installation of packages
• single package registry (npmjs.com ever go down for you?)
• requires network to install packages (though we can create a makeshift cache)
• allows packages to run code upon installation (not good for security)
• indeterminate package state (you can’t be sure all copies of the project will be using the same package versions)

Yarn solutions

• multiple registries - Yarn reads and installs packages from both npmjs.com as well as Bower. In the event one goes down, your project can continue to be built in CI without issue
• flat dependency structure - simpler dependency resolution means Yarn finishes faster and can be told to use a single version of certain packages, which uses less disk space
• automatic retries - a single network request failing won’t cause an install to fail. Requests are retried upon failure, reducing red builds due to temporary network issues
• parallel downloads - Yarn can download packages in parallel, reducing the time builds take to run
• fully compatible with npm - switching from npm to Yarn is a no friction process
• yarn.lock - keeps dependencies locked to specific versions similar to Gemfile.lock in the Ruby world

V JS se moc nepohybuju, co na to říkáte vy, kteří v něm děláte hodně? Ty změny na mě působí velmi racionálně, až se divím, jak vůbec něco mohlo fungovat bez nich (hlavně zamknuté verze v yarn.lock, woot?).

npm pro produkční nasazení na velkých projektech je nepoužitelné, končí to vlastním npm registry, balením kódu do taru/rpm, neustálým schvalováním patchů a nových verzí (přece si do infrastruktury nepustím neověřený kód).Ve zmíněných problémech npm (i yarnu) mi ještě chybí nulová provázanost s konkrétním repositářem a nemožnost si npm balíček vydeployovat automatizovaně ze zdrojového kódu aneb řečeno nemám žádnou jistotu, že npm/yarn balíček je opravdu ten kód, který je na githubu.Funguje to, protože ti malí bastlíři to neřeší a je jim bezpečnost a provoz šumák a ti velcí si to dopíši sami. Zajišťoval jsem prostředí pro cca 40 node.js vývojářů na jednom projektu a všechny zmíněné problémy se musely řešit vlastním upraveným klientem, naklonovaným public repositářem a obrovským množství ruční práce při kontrole balíčků. Kromě yarn.lock žádné z věcí co řeší yarn není kritická a dá se s ní žít, bohužel opět moc bezpečnost a transparentnost neřeší.