YARN or NPM? Choose yarn. Right now!

nothingismagick

I just wanted to put down a collection of links and info about why I think that yarn is the right choice in general, and why I feel that it is the direction that quasar should take.

Time

npm install @babel/core --save > 12.721s reported vs 0m13.395s (time)
yarn add @babel/core > Done in 3.98s. reported vs 0m4.480s (time)

Yarn has emoji. Interactive upgrading looks modernish. It caches and uses the cache intelligently. Less typing and less waiting means longer life - and faster CI.

Registry problems (hits yarn & npm)

I am a teapot. Proxy requests broken, downgrade to Node 4 - fix made about 6 hours after report

NPM PROBLEMS:

A feature request in npm since 2012: “Allow subdirectories within git repos in npm install” > https://github.com/npm/npm/issues/2974
Possibly the reason why you sometimes have to delete the entire node_modules folder and rerun npm install: SHA1 collision. > https://github.com/zkat/cacache/issues/85
“npm install --global” throws errors without sudo on linux
upgrading quasar can sometimes inexplicably cause failures with babel linkage. (tip - upgrade npm)

Catastophic loss of files

npm link fails and deletes folder contents (v3.10.9, v4.2.0)
minor stable release of npm destroys linux systems (v5.7.0) - updating npm with npm did it, because npm itself ignored version hint @next!

Yarn wins again:

Something that won’t work in npm, but works out of the box in yarn-managed package.json > “test-base”: “link:./packages/base”

Management of and interaction with monorepos

No real strategy for this with NPM - lerna is the current frontrunner, and they even offer several “yarn-only” features, such as workspaces.
Also new on the scene (and promising) is bolt - which is yarn based.

Yarn is deterministic and NPM is not. eg. The same lockfile can produce different installs on different machines or in different circumstances… (Thanks @panstromek)

Comments?

Frosty-Z

Hello,

I don’t intend to start flame wars but helping picking the right tools.

The npm vs yarn fight looks more balanced than a few months ago.

For the biggest concerns, npm v5 introduced package-lock.json & its performance has significantly improved (even if yarn remains slightly on top).

Some folks are even going back from yarn to npm : see yarn vs npm 2018 and npm vs yarn 2019

Note that all the arguments are not up-to-date, for example there is YVM which helps overcoming the “different yarn versions across projects” problem.

While this competition looks good to get better quality package managers in the long run, IMO for Quasar that brings some unnecessary mess :

Inconsistencies in docs : Quasar v1.0 installation shows npm instructions only, whereas best practices in upgrade guide recommends yarn => why not recommending it on install page too?
yarn seems to solve problems when developing on windows => maybe show that warning on install page too, when detecting a windows machine (user agent…)?
More problems : npm and yarn come with their own sets of problems, which I guess are piling up in support channels (forum, Discord…). However, choosing “strictly” one over the other would certainly hurt developers. npm is still “de facto” standard, and yarn got a lot of adoption when it had clear advantages over npm and all those devs won’t like to change back, even if the differences look now much closer.

For the moment, I would suggest the following to improve Quasar doc:

On installation page, I would state clearly that either npm & yarn can be used with Quasar. As well, if the Quasar core developers favor one over the other, it should be stated and explained (if possible, with detailed & up-to-date arguments)
On each command line involving the package manager, I would add some tab or button allowing to switch between npm and yarn instructions & keep the latest choice as a preference (maybe in a cookie) to be consistent across pages, when coming back to doc, etc.
Therefore, the doc would “support” the two mostly used package managers, follow the developer preference, and remain concise.

Such a flexible display could even support future & not yet popular package managers, like the very promising pnpm.

turigeza

I was using yarn both globally and locally. Then two days ago I was following the upgrade guide to quasar 1.
https://v1.quasar-framework.org/start/upgrade-guide

And I could not get passed the line

module.exports = {
  presets: [
    '@quasar/babel-preset-app'
  ]
}

that is until switched to npm for global use. Why that is I have no idea : ) but now I have npm for global use and yarn for local / per project use.

Worth noting their suggestion:
6. We recommend yarn whenever possible because of its speed and efficient use. However, when using globals, we still recommend using npm, especially if you use nvm (Node Version Manager).

I would love not to have to deal with both.

Hawkeye64

Pick the best tool for the job. NPM for global packages, Yarn for local packages. For now, this is the best set up. We do wish they both worked as expected for global and local packages, but the fact is right now, we help so many people with issues and a lot of times it’s migrating them to yarn for local packages and then things automagically work as expected.

No More Posting New Topics!