Now that I think about it, now that the cache and the node_modules are effectively the same, the results aren't as easy to interpret 🤔 Hmm maybe the "n/a" approach was more sensible ...

I'll restore the n/a, use a different color for Yarn 2.x, add the "1.x" label to the column, and maybe sort the table so that all the "caches" / "no caches" are put together - it really highlights where is 2.x faster or slower.

Btw@zkochan, what's your secret sauce for "cache / no lockfile / n_m"? I'd expect it to take at least the time needed to fetch the metadata from the registry 🤔

I think that case is so fast because even though there is no lockfile near the package.json, there is still a lockfile duplicate insidenode_modules/.pnpm/lock.yaml.

pnpm has two lockfiles. They have the same format. One is in the same folder in which package.json and the other one inside node_modules. This is great because after a branch switch, for instance, we just make a diff of the two lockfiles and we know what to remove or add.

It would be nice to update the benchmarks to use Yarn 2. I'd love to see how pnpm v5 performs compared to it.

Anyone working on getting this merged?

I don't think so because Yarn now maintains its own benchmarks:https://yarnpkg.com/benchmarks

I think I would prefer to keep only benchmarks that compare non-PnP package managers in this repo: npm7, pnpm, and Yarn2 with node-linker=node-modules

and we can add a link to Yarn benchmarks to see how PnP performs compared to pnpm.