feat: package-managers as default, redirects and more info

[ovflowd]

Description

This PR does a few changes on our Downloads page such as:

• Ordering the Package Manager Tab as the first and default one
• /download redirects to /download/package-managers
• The previous /download is now at /download/prebuilt-installers
• Added more information regarding each package manager (how to get them installed, if they're officially supported, etc)
• Updated Warnings and community info that bugs on package managers should not be reported to us

Screenshots

Validation

All the download pages are working as expected

Related Issues

Relates to nodejs/package-maintenance#591

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	May 15, 2024 8:50pm

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 97	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 93	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 99	🟢 100	🟢 100	🟢 92	🔗

[github-actions]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	90.06% (589/654)	76.08% (175/230)	92.24% (119/129)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
128	0 💤	0 ❌	0 🔥	6.195s ⏱️

[GeoffreyBooth]

Thanks, these are good improvements. It doesn’t solve nodejs/package-maintenance#591, as that issue notes that the problem cited in that issue is present when a system package manager such as Homebrew is used; but the changes in this PR set the stage for a follow-up where we revise the list of package managers and their instructions to be ones that don’t present the “globally installed npm” issue.

[AugustinMauroy]

LGTM !

[ovflowd]

@GeoffreyBooth I believe this PR solves the aforementioned issue

as that issue notes that the problem cited in that issue is present when a system package manager such as Homebrew is used; but the changes in this PR set the stage for a follow-up where we revise the list of package managers and their instructions to be ones that don’t present the “globally installed npm” issue.

If you check the tabs, we added extra information when you select a package manager... For example:

[GeoffreyBooth]

@mcollina should confirm, but when I read nodejs/package-maintenance#591 (comment)

The list of things that creates this kind of permission issues for our users:

1. distro-specific packages (deb, rpm, brew, port, …)

I assumed this meant that any installation via brew, for example, would produce the problem described in that issue. Perhaps we need a better definition of the problem, including steps to reproduce, to know which specific package managers have the problem? I think it’s something along the lines of “after following the provided steps to install Node and npm, running npm install -g npm@latest works without requiring sudo.” Maybe that’s already true for all the package managers cited on the webpage, but since brew was mentioned in the issue and it’s still one of the package managers on the page, I assume that the issue hasn’t been resolved.

Regardless, I still like the changes in this PR and think that they’re a step forward, and we can do further iterations in a follow-up. We don’t need to fix nodejs/package-maintenance#591 in a single PR. This PR doesn’t resolve nodejs/package-maintenance#598 either, but helps a lot in that whatever PR is created to tackle that one can be much smaller once this PR lands.

Edit: I think part of the confusion might be stemming from the fact that we’re using the term “package manager” to refer to two different things: the system package manager like Homebrew or Choco, and the app dependency package manager like npm. nodejs/package-maintenance#591 is talking about how system package managers such as Homebrew install npm so that npm needs administrator rights to run, when npm shouldn’t need sudo.

[canerakdas]

LGTM 🚀

While checking the pages, I noticed that the codebox component was causing the layout shift on this page. Since this development has no regression, I will open a separate PR to fix

[ovflowd]

Thx for the explanation, @GeoffreyBooth, indeed the npm sudo issue feels tricky. It definitely feels like a mistake on the user side and probably due to them installing homebrew with sudo?

Anyhow, Ill update the PR description stating that this PR doesnt fix the issue. Id love to know what next steps should be 🤔

[GeoffreyBooth]

Anyhow, Ill update the PR description stating that this PR doesnt fix the issue. Id love to know what next steps should be 🤔

Well we should still land this PR. This takes a step in the right direction for both the “help users avoid needing sudo“ and the “encourage users to use a version manager” goals.

After that, it might make more sense to first focus on the latter goal, of encouraging installing Node in a manner where it’s easy to swap versions when changing projects. As in, the user’s machine has project foo that needs Node 22, and project bar that needs Node 20; it should be easy to switch back and forth between projects and change the Node version accordingly (or run the correct Node version per project). I’m assuming that that’s not even possible for installation methods such as Homebrew or Chocolatey or apt-get etc.; is it? If it’s not, then either we should move those methods to a different tab (for the “I have no need to use more than one version of Node.js” use case, such as for a Docker container or a single-purpose machine like a kiosk) or simply delete them. Then we should add more options that do satisfy this “switch versions per project” use case, beyond just nvm, so that we have at least one recommendation for each platform and ideally a few good ones for the most popular platforms. Ideally the version manager handles both the runtime and the app package manager (npm or Yarn or pnpm) either as one tool such as Mise or asdf or as a combination of two like nvm + Corepack.

Anyway if we tackle that work first, and as a result we end up dropping some of the current package managers, then we don’t need to worry about solving permissions-related issues with the dropped package managers. And we can ensure that any new installation instructions we write don’t have the sudo issue.

[ovflowd]

Anyhow, Ill update the PR description stating that this PR doesnt fix the issue. Id love to know what next steps should be 🤔

Well we should still land this PR. This takes a step in the right direction for both the “help users avoid needing sudo“ and the “encourage users to use a version manager” goals.

After that, it might make more sense to first focus on the latter goal, of encouraging installing Node in a manner where it’s easy to swap versions when changing projects. As in, the user’s machine has project foo that needs Node 22, and project bar that needs Node 20; it should be easy to switch back and forth between projects and change the Node version accordingly (or run the correct Node version per project). I’m assuming that that’s not even possible for installation methods such as Homebrew or Chocolatey or apt-get etc.; is it? If it’s not, then either we should move those methods to a different tab (for the “I have no need to use more than one version of Node.js” use case, such as for a Docker container or a single-purpose machine like a kiosk) or simply delete them. Then we should add more options that do satisfy this “switch versions per project” use case, beyond just nvm, so that we have at least one recommendation for each platform and ideally a few good ones for the most popular platforms. Ideally the version manager handles both the runtime and the app package manager (npm or Yarn or pnpm) either as one tool such as Mise or asdf or as a combination of two like nvm + Corepack.

Anyway if we tackle that work first, and as a result we end up dropping some of the current package managers, then we don’t need to worry about solving permissions-related issues with the dropped package managers. And we can ensure that any new installation instructions we write don’t have the sudo issue.

Thanks for the extra info; I appreciate it.

[ovflowd]

I think some of the current ones like Homebrew don't manage versions, do they? They just install the latest version only.

That's correct.

[wesleytodd]

I asked for feedback on the header "Package Manager" to my team and they all had the miss understanding that in that page the term meant "npm or yarn". We discussed if maybe something more generic like "recommended" would be better since what we are saying with this change is that we are recommending this as the primary installation method.

I looked at what the PR would take and since it needed to use the translations and the name of that key was package-manager I wanted to ask before I opened a PR to gauge if folks thought this would be a good change.

[MattIPv4]

Personally, I would be comfortable with calling this "Version Managers". I acknowledge not all of them strictly allow for controlling multiple versions, but I think it's a bit clear for the grouping of things under the tabs than just calling it "Recommended"?

[wesleytodd]

I also think that is better language than the current, but I acknowledge that some folks might be worried about it not being "technically correct".

[GeoffreyBooth]

I think the tab should be called version managers and it shouldn't include any installation methods that don't allow for running different versions of Node and different package manager versions per project. That's what we agreed to in the goals doc. We can follow this up with a PR that makes the change.

Another approach would be tab names like "Install for development" and "Install on a server". The former would be version managers like Mise and the latter would be ones like Homebrew.

[wesleytodd]

it shouldn't include any installation methods that don't allow for running different versions of Node and different package manager versions per project. That's what we agreed to in the goals doc.

I don't think I follow fully. I think what we agreed upon in the doc is the "end state" we would like to achieve. Since the most popular tools in this space don't fully meet our end goal I think what we landed here was a "first step". I think it would be worse for users in the mean time to have less tools listed here than we do, and I was only trying to advocate for a small wording tweak.

Another approach would be tab names like "Install for development" and "Install on a server".

Yeah, this is the kind of wording brainstorming we were trying to do when landing on "recommended". I like these phrases quite a bit (I also still like version managers personally as well) but the would require more UI changes than just a language tweak. Maybe that is alright, so if that is what we want to do I am good with that. I would still think it is best to keep the default tab to be the exact combination of settings we have now (for development, your os, nvm).

[ovflowd]

I think it would be worse for users in the mean time to have less tools listed here than we do, and I was only trying to advocate for a small wording tweak.

Agreed. It is unreasonable (IMO) to simply stripe away Chocolatey and Homebrew which are some of the most popular ways of installing Node.js whilst we don't have a concrete solution for system package managers to properly offer all versions... But I'm open to suggestions.

Yeah, this is the kind of wording brainstorming we were trying to do when landing on "recommended". I like these phrases quite a bit (I also still like version managers personally as well) but the would require more UI changes than just a language tweak. Maybe that is alright, so if that is what we want to do I am good with that. I would still think it is best to keep the default tab to be the exact combination of settings we have now (for development, your os, nvm).

That's an interesting approach, definitely worth exploring.

I think the tab should be called version managers

This is the sort of naming that I believe requires some sort of poll on twitter or survey. It might make sense for us, but it has been "Package Managers" since always and changing the naming now could confuse a lot of people.

[wesleytodd]

it has been "Package Managers" since always and changing the naming now could confuse a lot of people.

Ah, honestly I don't remember seeing that wording before. I was basing it on my reaction and then asked my team to give feedback and it aligned with my thinking. That said, if this predates this change (which I just learned now) then I guess maybe we are good just leaving it be.

[ovflowd]

it has been "Package Managers" since always and changing the naming now could confuse a lot of people.

Ah, honestly I don't remember seeing that wording before. I was basing it on my reaction and then asked my team to give feedback and it aligned with my thinking. That said, if this predates this change (which I just learned now) then I guess maybe we are good just leaving it be.

I'm fine either ways, just want to ensure we're not rushing with something.

[GeoffreyBooth]

Well just a few weeks ago the download page looked like this: https://web.archive.org/web/20240301012624/https://nodejs.org/en/download/ So I don’t think there’s some longstanding history around “package managers.”

The current tabs are “Package Manager”, “Prebuilt Installer”, “Prebuilt Binaries”, “Source Code”. What are the use cases for “Prebuilt Binaries” and “Source Code”?

[ovflowd]

Well just a few weeks ago the download page looked like this: web.archive.org/web/20240301012624/https://nodejs.org/en/download So I don’t think there’s some longstanding history around “package managers.”

Yes there is. Did you miss this?

[ovflowd]

The current tabs are “Package Manager”, “Prebuilt Installer”, “Prebuilt Binaries”, “Source Code”. What are the use cases for “Prebuilt Binaries” and “Source Code”?

For folks that want to download the zipped source code of a said version and folks that want to download prebuilt binaries? These options have been there for ages, and I don't think we should remove them on a "whim".

[GeoffreyBooth]

I saw it, but it’s a link down at the bottom of the page, after “Signed SHASUMS for release files (How to verify)” and “All download options”. It’s practically buried. The new prominence of “Package Managers” is only a few weeks old.

For folks that want to download the zipped source code of a said version and folks that want to download prebuilt binaries? These options have been there for ages, and I don’t think we should remove them on a “whim”.

Why would people want to do either of those? I’m not suggesting we remove them. I’m asking why people are going to those tabs.

[ovflowd]

I saw it, but it’s a link down at the bottom of the page, after “Signed SHASUMS for release files (How to verify)” and “All download options”. It’s practically buried. The new prominence of “Package Managers” is only a few weeks old.

Being buried down != people not using'em. The "Installing via Package Manager" is a highly accessed link and also a top search result on Google.

Why would people want to do either of those? I’m not suggesting we remove them. I’m asking why people are going to those tabs.

Is this a question directed to me or to the open? 🤔

[GeoffreyBooth]

Is this a question directed to me or to the open? 🤔

I’m asking anyone who knows the answer. Earlier we were discussing renaming the tabs based on use case, like “Install for Development” or “Install on a Server.” Let’s say we did so, and had enough tabs to cover our main use cases plus maybe a catchall like “Other.” What use case-based tabs would get the prebuilt binaries links? The source code links?

In https://linuxfoundation.surveymonkey.com/r/nodenext10survey24 we have a question that asks about core Node use cases:

6. What is your primary use case for Node.js?

• CLI tools
• Testing
• Development of APIs with Microservices
• Development of APIs with Serverless
• Development of APIs with Other
• Building static front end applications
• Deploying front end applications (Next.js, Remix, etc…)
• Script and automation (bots, scrapers)
• Proxy
• Other (please specify)

If were were to translate this into tabs for the Download page, what would those tabs be named and which download links/instructions would go under each tab?

I’m not sure that this is a better approach than simply describing the various download options, as we do now, but I think it’s worth sketching out what this would look like and evaluating it in comparison.

[ovflowd]

I’m asking anyone who knows the answer. Earlier we were discussing renaming the tabs based on use case, like “Install for Development” or “Install on a Server.” Let’s say we did so, and had enough tabs to cover our main use cases plus maybe a catchall like “Other.” What use case-based tabs would get the prebuilt binaries links? The source code links?

I see from where you're coming from. That's interesting. I agree that we could redesign the tabs to be:

• Install for Development / Local use (Version Managers)
• Install for Production (Installers) (Or System Package Managers)
• Other (Source Code / Binaries)

Would this maybe make sense? 🤔

I’m not sure that this is a better approach than simply describing the various download options, as we do now, but I think it’s worth sketching out what this would look like and evaluating it in comparison.

Can agree. The current tab layout can be confusing; I misunderstood your previous statement as simply removing said options. My bad!

[GeoffreyBooth]

Would this maybe make sense? 🤔

Yes, I think this is quite good. We can workshop it a bit, like I wonder if “Local use” is too vague (could be either developing apps or running scripts/CLI tools) and would someone think to look under “Install for Production” if they want a graphical installer; but this is a good start. Another approach is maybe “Install for Development”, “Install for Production”, “Downloads” where the first two are various instructions and the last one is links.

The one that I would maybe remove is “download source code”. Really, who is using this one? Do we have any analytics on it? Why would someone download our source from here rather than checking out the git repo, or downloading the source from git? Though if we have an “Other” or “Downloads” tab then we can put all the miscellaneous links like this under there.

[ovflowd]

The one that I would maybe remove is “download source code”. Really, who is using this one? Do we have any analytics on it?

I can check Sentry session replays to see how many folks are clicking on this. Allow me some time to collect the data.

[GeoffreyBooth]

Speaking of more data, while we await the 2024 survey results in a few weeks the 2023 results are in https://github.com/nodejs/next-10/tree/main/surveys/2023-04. It was slightly different but it had some relevant questions:

• How do you get your Node.js executables? (multiple choice)
  • With a Node.js version manager: nvm, n, nave, nvs, volta, etc.
  • Using the official installer
  • Using package managers like npm or yarn and install Node.js as a package
  • Using a system package manager: apt-get, brew, dnf, yum …
  • Downloading binaries directly from Nodejs.org
  • Building Node.js from Source
  • Other

Q13: How do you get your Node.js executables? - Other

• asdf

• asdf

• asdf

• Bazel

• Brew for macos

• Chocolatey

• Corepack

• Docker

• Docker

• Docker

• Docker

• docker

• Docker

• Docker

• Docker

• Docker

• Docker

• Docker

• docker container

• Docker dev environment

• Docker files

• Docker hub

• Docker image

• Docker image

• Docker image

• Docker image

• docker image

• Docker image

• docker image

• Docker image

• Docker image (e.g. node:lts-alpine)

• Docker image with node.js already installed

• Docker images

• Docker images

• Docker images

• Docker images

• Docker in Prod

• Docker pull

• Docker Pull

• Dockhub

• Fnm

• from official Node Docker image and lightweight custom image based on executables

• from official

• ibm rpm

• Installed in Dockerfile

• NodeSource

• Nodesource, also whatever GCP has built in

• Official docker image

• official docker images

• Official docker images

• Official Docker images (deployments)

• Official Docker node image

• Other (please specify)

• Pnpm env use

• Pre-built docker images

• Prod env: Docker images

• Scoop

• Using docker

• Using the official Docker Image

• Version manager

• If you use a version manager which one do you use (multiple choice - Other should give an input)

• nvm

• n

• nave

• nvs

• volta

• Other ?

Q9: Which version manager do you use? - Other

• adsf
• apt
• apt
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• Asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• asdf
• ASDF
• brew
• brew
• Brew
• Containers and Virtual Machines
• corepack
• Corepack
• custom
• Do not use
• Docker
• Docker
• Docker images
• docker images specify the version
• Docker node:* images
• Don’t use
• Don’t use at all
• Don’t know
• Don’t use
• Fast Node manager
• fem
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• Fnm
• fnm
• Fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• Fnm
• fnm
• fnm
• fnm
• fnm
• Fnm
• fnm
• fnm
• fnm
• fnm
• Fnm
• fnm
• fnm
• fnm
• Fnm
• FNM
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• fnm
• Fnm
• fnm
• Git
• Git
• Homebrew
• https://github.com/jdxcode/rtx
• I don’t
• I don’t know
• I don’t use a version manager as long as nodejs doesn’t embed a version manager like NPM
• I don’t use a version manager.
• I dont use it, instead I use alter native on Ubuntu or docker with pre installed version
• I prefer not to use one
• I use pnpm to manage multiple node versions
• manually setup in the docker container
• my own bash scripts
• N/A
• n/a
• N/A
• Na
• Nill
• nimble
• nix
• No
• no
• no i install from my dixtro package manager: dnf
• nodeenv
• nodenv
• nodenv
• Nodenv
• nodenv
• nodenv
• nodenv
• None
• None
• None
• none
• None
• none
• None
• none
• None
• None
• None
• None
• none
• None
• None
• None
• None
• none
• None
• None
• none
• None
• None
• None
• None
• None
• None
• None
• None
• none
• none
• None
• None
• none
• None
• None
• None
• none
• none
• None
• none
• None (over docker)
• None of them
• None of these
• None. Always latest lts
• None. I’m really old school with server management
• Not using
• Not using one
• Npm
• npm version
• nvm || laragon
• nvm and pnpm, depending on project
• nvm for windows (same name different project iirc)
• nvm for windows, nodebrew, volta
• nvm-windows
• nvm, but moved to asdf
• nvm.fish
• Only use latest version (operating system)
• Other (please specify)
• pnpm
• pnpm
• pnpm
• Pnpm
• pnpm
• pnpm
• pnpm (it does node version management)
• pnpm env
• PPA / Docker
• rtx
• rtx
• Scoop
• Self buit script
• systemd portable services, Docker
• Unknown
• V

Q6: What is your primary use case for Node.js? - Other

• Automation
• Automation QA
• Azure Functions
• Bots
• Bots, scripts, parsers…
• Build systems
• Cli tools
• Cli tools
• cli tools, data migrations
• CLI’s & Tooling
• CLI/utilities/packages
• CLIs
• Developer tooling
• Developer tooling (CLI tools)
• developing library for end to end testing
• DevX tooling
• I don’t neccessarily use it for custom backends (APIs), but because frameworks like Next.js uses it for SSR.
• library / framework development
• linting and legacy build steps
• Nim lang wrapping and extensions
• Quick scripts
• scripting
• Serverless, (aws lambda, gc functions)
• Small tools
• Software engineer in test
• Solving ProjectEuler.net problems
• Some command line applications
• Standalone Products
• Still learning
• Test Automation
• Test automation
• Testing
• Testing
• Testing (jest)
• Tooling
• Tooling
• Tooling, CLIs, etc
• Unit testing
• vite, webpack, code generation, npm
• Web scraping
• WebRTC, NodeOS