Adopt pnpm as a package manager for this Repository

[ovflowd]

Hey, you all 👋 after doing some experimentation, I wanted to ask the team (cc @nodejs/website) what you think about adopting pnpm as the package manager for this repository.

Some of the key caveats/benefits I've noticed:

• Installing packages on CI reduced 60% from (varying 20-50seconds to blazingly 4-7 seconds)
• Running package binaries do not require npx
• Native monorepo support if we ever need
• Smaller node_modules and cache footprint (making the GitHub Actions cache storage have more space) (Around 70% less footprint)

Some of the disadvantages:

• Requires Extra Step on CI to install PNPM or use Corepack
• Not natively installed with Node.js, so newcomers need also to install pnpm

I also want the opinion of the @nodejs/build team and the TSC @nodejs/tsc as I want to ensure that this change is not controversial nor conflicting with any of our bylaws and/or creates an adverse affect on the "npm" package manager (as if this repository does any endorsement to pnpm over npm which is not the case).

[mhdawson]

My initial thought is that what is most important is how easy it is to contribute a change to the website. I'm less worried about things taking a bit longer in our CI.

Are there any significant benefits to people submitting a PR in terms of the overall time that will take them? If not I think avoiding people having to do an additional install may not be worth it.

[ovflowd]

That is a great argument. And I'm in favour of it. If ultimately what matters is DX, adding another layer of dependency that requires another install on the userland can be discouraging and add extra debugging/issues to the contribution cycle towards this repository.

And a few seconds of CI time is not a big deal. Again the idea of adopting pnpm has its pros and cons.

And truth be said, npm is more than sufficient, and I see no issues with keeping it at the time of writing this. (NPM is darn great).

[AugustinMauroy]

With PNPM it's possible to keep package.json and package-lock.json and just use PNPM on CI CD ?
In this case PNPM will be great.

[AugustinMauroy]

So I don't thinks it's good idea to adopt PNPM.

[ovflowd]

@AugustinMauroy pnpm has it's own lockfile format.

[AugustinMauroy]

If I made an summarize

• npm support package.json
• yarn support package.json and yarn-lock-yml
• pnpm suport package.json and?pnpm.yml

So with this we can say
We should keep npm and if people use pnpm or yarn it is to their will

[ovflowd]

No? We should not allow users to arbitrarily decide which package manager they use. If we stay with npm they need to use npm.

But both yarn and pnpm "support" reading the package-lock.json, just for reference. So theoretically they can use and respect the versions. But anyhow that's off-topic.

[aduh95]

Imposing a specific package manager is a very common practice, the same way we impose e.g. using node, even though it might work to run the code with a different JS runtime; it’s easier for everyone if we’re all on the same page.

[ovflowd]

Hey, @nodejs/website, I want your opinions if we should adopt pnpm or not. During some tests, I've been doing lately:

• Cold (without cache) installs of Node.js NPM packages takes 1~ minute
• Cold (without cache) installs of Node.js NPM packages with PNPM takes ~10 seconds
• Warm installs of Node.js NPM packages takes 25 seconds to 50 seconds
• Warm installs of Node.js NPM packages with PNPM takes ~5 seconds

This is a considerable enough change to speed up the deployment process, PR reviews, and all the numerous different GitHub Actions we have.

I wanted to ask your opinions on adopting pnpm or not. It is a good enough change and it brings other benefits (possibly on the long term)

[ruyadorno]

it should be install-strategy=linked iirc, it's pb still experimental though

[ovflowd]

@ruyadorno being on the edge is my family name

[ovflowd]

Well, yeah it didn't work 😅

npm WARN reify The "linked" install strategy is EXPERIMENTAL and may contain bugs.
npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm ERR! code 1
npm ERR! path /Users/cwunder/GitHub/Personal/nodejs.org/node_modules/.store/esbuild@0.17.19-lPWS9eySCA4LWj0y2ZksTQ/node_modules/esbuild
npm ERR! command failed
npm ERR! command sh -c node install.js
npm ERR! node:internal/errors:868
npm ERR!   const err = new Error(message);
npm ERR!               ^
npm ERR! 
npm ERR! Error: Command failed: /Users/cwunder/.nvm/versions/node/v18.13.0/bin/node /Users/cwunder/GitHub/Personal/nodejs.org/node_modules/.store/esbuild@0.17.19-lPWS9eySCA4LWj0y2ZksTQ/node_modules/esbuild/bin/esbuild --version
npm ERR! /Users/cwunder/GitHub/Personal/nodejs.org/node_modules/.store/esbuild@0.17.19-lPWS9eySCA4LWj0y2ZksTQ/node_modules/esbuild/bin/esbuild:1
npm ERR! ����

[ruyadorno]

that's a bummer, it looks like for some reason esbuild doesn't like the location it has been assigned by the linked install strategy 😅

[ovflowd]

Important to mention that installing NPM packages is taking around 2-3 minutes on Windows (GitHub Actions)

[AugustinMauroy]

JFYI pnpm wasn't support by dependabot

[ovflowd]

We don't use dependabot right now.

[bmuenzenmeyer]

I've found value in pnpm for dedicated app teams using the software day in and day out, switching branches, installing dependencies, etc.... but it's benefits add up the more you use it. I think what @mhdawson said is probably the overriding concern here: ease of initial contributon. Maybe corepack helps enough here, but that feels too new IMO.

Imposing a specific package manager is a very common practice

https://github.com/pnpm/only-allow can help here if we choose to codify npm (or otherwise)

[ovflowd]

Yeah, I think these points are worth considering! I definitely wonder how easy newcomers could setup pnpm

[bmuenzenmeyer]

As an aside, I've yet to find a great way to pin a version of npm or pnpm to a project... nvm sorta works by virtue of defining a Node.js version and then assuming users take the bundled npm version.

Perhaps something like volta could help - but here we are again talking more tools in an environment that needs to be simple.

Project setup is all about determinism and simplicity to me, and I'm not sure anything meets that mark aside from good docs (and ...perhaps... nvm)