search

nodejs / nodejs.org

The Node.js® Website
https://nodejs.org
MIT License
6k stars 6.16k forks source link

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

Closed ovflowd closed 1 month ago

ovflowd commented 1 month ago

Description

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

Screenshots

image

Validation

All the download pages are working as expected

Related Issues

Relates to https://github.com/nodejs/package-maintenance/issues/591

vercel[bot] commented 1 month ago

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[bot] commented 1 month ago
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[bot] commented 1 month ago

Unit Test Coverage Report

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

Unit Test Report

Tests Skipped Failures Errors Time
128 0 :zzz: 0 :x: 0 :fire: 6.195s :stopwatch:
ovflowd commented 1 month ago

@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:

image

GeoffreyBooth commented 1 month ago

@mcollina should confirm, but when I read https://github.com/nodejs/package-maintenance/issues/591#issue-2198202214

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 https://github.com/nodejs/package-maintenance/issues/591 in a single PR. This PR doesn’t resolve https://github.com/nodejs/package-maintenance/pull/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. https://github.com/nodejs/package-maintenance/issues/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.

ovflowd commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.

wesleytodd commented 1 month ago

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

I agree the terminology here might be confusing to folks even if it seems technically correct imo. I wonder if we should call these "version managers" or something even though that is a weird distinction to make.

GeoffreyBooth commented 1 month ago

I wonder if we should call these "version managers" or something even though that is a weird distinction to make.

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

I still think we should have a tab specifically for version managers like nvm and Mise, and these "install latest only" tools can get their own tab.

ovflowd commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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?

image

ovflowd commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

  1. 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 commented 1 month ago

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:

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

image

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

image

Q9: Which version manager do you use? - Other

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