pnpm / benchmarks-of-javascript-package-managers Goto Github PK

This flag could introduce some performance enhancements

Since Yarn 2 has PnP enabled (with a better implementation as Yarn 1), I think it would make more sense to use that.

To use Yarn 2, the following command has to be run within the project outside of the benchmark:

yarn policies set-version berry

Some other particularities:

• to remove the cache, better use yarn cache clean --all. You also can add enableGlobalCache which will use a unique cache (otherwise it'll have a first global cache, then a per-project cache).

• when removing the n_m, you'll instead want to remove the .pnp.js file for PnP (I think it's currently marked as n/a)

npm 7 was released 10 days ago. Apparently they've made some performance improvements. Can the benchmarks be updated?

https://github.com/npm/cli/releases

Thanks

its a grate package manager "pnpm" .
thanks for making this thing .

now , i have noticed some issue with pnpm last day
the issue is,
when i am trying to install material-components-web with pnpm its installing the main package not
@material/** dir
but when install with npm its doing the complete install
though i got a work aroung is to copy the @material dir to node modules.

but i though it need to be noticed by u guys .

thanks again..
lots of love

https://github.com/duojs/duo

Throws error while on Windows 10

Nogr@Gaming-Fury MINGW64 /c/Projects/Development/Nodejs/benchmark-package-managers (feat/windows-compability-fix)
$ npm run prebenchmark

> [email protected] prebenchmark C:\Projects\Development\Nodejs\benchmark-package-managers
> rimraf .tmp


Nogr@Gaming-Fury MINGW64 /c/Projects/Development/Nodejs/benchmark-package-managers (feat/windows-compability-fix)
$ npm run benchmark

> [email protected] prebenchmark C:\Projects\Development\Nodejs\benchmark-package-managers
> rimraf .tmp


> [email protected] benchmark C:\Projects\Development\Nodejs\benchmark-package-managers
> node index

# first install
> npm install --ignore-scripts --cache cache --registry https://registry.npmjs.org/
Error: npm failed with status code null
    at measureInstall (C:\Projects\Development\Nodejs\benchmark-package-managers\lib\benchmarkFixture.js:163:11)
    at benchmark (C:\Projects\Development\Nodejs\benchmark-package-managers\lib\benchmarkFixture.js:64:24)
    at async module.exports (C:\Projects\Development\Nodejs\benchmark-package-managers\lib\recordBenchmark.js:20:22)
    at async run (C:\Projects\Development\Nodejs\benchmark-package-managers\index.js:109:28)

It would be nice if the benchmark also tracked how long it took to install (ie. add) modules, after the project has already been fully installed/initialized.

This is an important consideration, since it's the most common dependency-related operation that is performed (at least in my projects).

It's also significant because npm is actually faster than yarn for adding new modules -- at least for my project, with a package-lock present for both:

These commands were done in order, in the "mobx-devtools-advanced" repo, on 2019-11-13.

NPM version: 6.11.2
Yarn version: 1.19.1

* npm install [email protected]: 62s (slow since had to clear yarn metadata + rebuild it)
* npm install [email protected]: 5s
* npm install [email protected]: 5s
* npm install [email protected]: 5s
* yarn add [email protected]: 48s (slow since had to clear npm metadata + rebuild it)
* yarn add [email protected]: 12s
* yarn add [email protected]: 10s
* npm install lodash @2.0.0: 67s (slow again due to rebuild)
* npm install lodash @2.1.0: 5s
* npm install lodash @2.2.0: 5s

Note that the operation of just adding a new module took about half as long for npm than yarn.

That said, both are quite fast, so perhaps it's not so important after all.

According to the website, one of the major features is pnpm's minimal disk usage. If it is possible, could you add sizes of the folders (with du -sh or something) to the benchmark, so we could see for ourselves?

Hi. For some reason I don't like to use the Lockfile. I'd like to find out what's the difference in speed when I have cache and node_modules folder, but no Lockfile.

Yarn has such test at https://yarnpkg.com/lang/en/compare/ but it's outdated.

Missing test-cases:
✔ Warm Cache ✔ node_modules ✗ Lockfile/Shrinkwrap
✗ Warm Cache ✔ node_modules ✗ Lockfile/Shrinkwrap
✗ Warm Cache ✔ node_modules ✔ Lockfile/Shrinkwrap

https://blog.npmjs.org/post/173260195980/announcing-npm6

Your benchmark doesn't packages which require native compilation.
Try to depend on truffle, for example. it depends on quite a few native modules.
NPM compiles them one by one. Yarn opens multiple parallel processes to compile, and achieves great efficiency.

Moreover, since re-install often requires to compile such native modules again (I don't really know why, but both NPM and Yarn do it) , the above compilation times affect not only initial installs but also re-installs.

The tables are labeled runtime in ms, but the measurements are all given in seconds. This should be consistent.

Couldn't find any information about this flag.

npm install --cache cache

Are there any explanation what it does or documentation about it?

Another benchmark that would be good to have is to measure how the different package managers handle updated dependencies. Take for example the dependencies of the React app package.json:

{
  // ...other package.json stuff
  "dependencies": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0",
    "react-scripts": "1.1.1"
  },
  // ...other package.json stuff
}

After all the currently available benchmarks are done (clean install, etc...) the dependencies could be updated and the update speed could be measured:

{
  // ...other package.json stuff
  "dependencies": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0",
    "react-scripts": "^2.1.8" // <===== changed
  },
  // ...other package.json stuff
}

This way the package managers don't just install new packages, but some packages also have to be deleted and/or rearranged. For me, updating my packgage.json and node_modules is a far more common use case than starting a new project.

What do you think?

Would be nice to have reports for module upgrades, like:

yarn upgrade webpack

Could you tell me why yarn install without param --registry when npm and pnpm have the param? Thank you!

In npm v5.7.1 a new command was added - npm ci. Npm team claims it is faster (2x-10x) than npm install

The new npm ci command installs from your lock-file ONLY. If your package.json and your lock-file are out of sync then it will report an error.

It works by throwing away your node_modules and recreating it from scratch.

Beyond guaranteeing you that you'll only get what is in your lock-file it's also much faster (2x-10x!) than npm install when you don't start with a node_modules.

As you may take from the name, we expect it to be a big boon to continuous integration environments. We also expect that folks who do production deploys from git tags will see major gains.

It feels like it is a totally different mode that is meant to offer huge speed improvement so would be good to have as a separate category