4 ms·

We have a monorepo with 200packages. NPM install times were longer than 1hour. Unusable. Yarn v2 took this down to 20 seconds. Yes, around 200x faster. They jus

We have a monorepo with 200packages. NPM install times were longer than 1hour. Unusable. Yarn v2 took this down to 20 seconds. Yes, around 200x faster. They just are not comparable on that aspect. The issues we had are with some packages who don’t list their peerDependencies correctly, or which assume the file structure of node_modules will be the one made by npm. But yarn has improved and these obstacles are much easier now.

dmitryminkovsky 5y ago
That is so appealing... I don't have a monorepo with 200 packages but I do `yarn install` in a Dockerfile and if something changed that uncached that line, the whole thing can take 10 minutes or more to download, unpack, install. Would love to try Yarn 2 (3, now, I guess) when I can. Does Rome use yarn? Anyone using Rome in production?
- city41 5y ago
  I haven't actually used Rome, but their installation guide mentions both yarn and npx, so that possibly means Rome is agnostic on them https://rome.tools/#installation-and-usage https://rome.tools/#installation-and-usage
- tuxie_ 5y ago
  If you are on mac, this is a known docker issue because in non-Linux systems fs access is virtualized (docker runs on an Ubuntu running on a vm). Becomes pretty unusable.
  - herpderperator 5y ago
    Not Ubuntu, but a very stripped down Linux install.
    - tuxie_ 5y ago
      Thanks for the clarification!
- ncrmro 5y ago
  When doing dev you can specify the workspace command and cache any node_modules etc in volumes locally which greatly increases local development speed when changing sepa. Eg no Docker file in dev unless you need custome system dependencies. Otherwise alpine node in Docker compose and in prod Docker file
breck 5y ago
We also had a >10x faster experience with Yarn. I don't understand why npm just can't improve perf. Seems fixable. In my smaller personal projects without as many dependencies, I just use npm and it's easier.
- zelphirkalt 5y ago
  I think part of any (perceived?) performance advantage comes from not being as safe as npm in terms of dependency resolution and lock file preciseness. I seem to get very little out of Yarn, considering its downsides, while npm on the other hand is the standard package manager and simple to use.
  - firebaze 5y ago
    Full disclosure, I don't have any experience with yarn aside from personal experiments, so I can't compare yarn with npm fairly. But is it possible that another package manager is even less safe than npm regarding dependency resolution? Ask your team the question: what's the difference between npm update, npm install, npm update --workspaces, npm install --workspaces, and how the outcome differs between npm versions. Bonus points for knowing in which scenario package-lock.json is taken into account. If yarn is even worse, my last hope is gone. Please don't take that post too seriously :)
    - bakje 5y ago
      Right? I'm a web developer and work a lot with PHP. PHP's de facto package manager is Composer and it's very simple and clear in how it works: Your composer.json states your dependencies and their version constraints. Your composer.lock (also a json file) states the actual versions that should be installed, based off your composer.json. "composer install" installs the exact versions from your composer.lock file, "composer update [package]" updates the lock file based on your constraints. With npm this doesn't seem to be as straight-forward, sometimes I run "npm install" and the package-lock.json ends up changing, I definitely don't consider npm to be safe.
      - 5y ago
deleted 5y ago
[deleted]

dmitryminkovsky 5y ago

That is so appealing... I don't have a monorepo with 200 packages but I do `yarn install` in a Dockerfile and if something changed that uncached that line, the whole thing can take 10 minutes or more to download, unpack, install. Would love to try Yarn 2 (3, now, I guess) when I can. Does Rome use yarn? Anyone using Rome in production?

city41 5y ago
I haven't actually used Rome, but their installation guide mentions both yarn and npx, so that possibly means Rome is agnostic on them https://rome.tools/#installation-and-usage https://rome.tools/#installation-and-usage
tuxie_ 5y ago
If you are on mac, this is a known docker issue because in non-Linux systems fs access is virtualized (docker runs on an Ubuntu running on a vm). Becomes pretty unusable.
- herpderperator 5y ago
  Not Ubuntu, but a very stripped down Linux install.
  - tuxie_ 5y ago
    Thanks for the clarification!
ncrmro 5y ago
When doing dev you can specify the workspace command and cache any node_modules etc in volumes locally which greatly increases local development speed when changing sepa. Eg no Docker file in dev unless you need custome system dependencies. Otherwise alpine node in Docker compose and in prod Docker file

breck 5y ago

We also had a >10x faster experience with Yarn. I don't understand why npm just can't improve perf. Seems fixable. In my smaller personal projects without as many dependencies, I just use npm and it's easier.

zelphirkalt 5y ago
I think part of any (perceived?) performance advantage comes from not being as safe as npm in terms of dependency resolution and lock file preciseness. I seem to get very little out of Yarn, considering its downsides, while npm on the other hand is the standard package manager and simple to use.
- firebaze 5y ago
  Full disclosure, I don't have any experience with yarn aside from personal experiments, so I can't compare yarn with npm fairly. But is it possible that another package manager is even less safe than npm regarding dependency resolution? Ask your team the question: what's the difference between npm update, npm install, npm update --workspaces, npm install --workspaces, and how the outcome differs between npm versions. Bonus points for knowing in which scenario package-lock.json is taken into account. If yarn is even worse, my last hope is gone. Please don't take that post too seriously :)
  - bakje 5y ago
    Right? I'm a web developer and work a lot with PHP. PHP's de facto package manager is Composer and it's very simple and clear in how it works: Your composer.json states your dependencies and their version constraints. Your composer.lock (also a json file) states the actual versions that should be installed, based off your composer.json. "composer install" installs the exact versions from your composer.lock file, "composer update [package]" updates the lock file based on your constraints. With npm this doesn't seem to be as straight-forward, sometimes I run "npm install" and the package-lock.json ends up changing, I definitely don't consider npm to be safe.
    - 5y ago

deleted 5y ago

[deleted]