-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: package-managers as default, redirects and more info #6720
feat: package-managers as default, redirects and more info #6720
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Lighthouse Results
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM !
@GeoffreyBooth I believe this PR solves the aforementioned issue
If you check the tabs, we added extra information when you select a package manager... For example: |
@mcollina should confirm, but when I read nodejs/package-maintenance#591 (comment)
I assumed this meant that any installation via 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🤔 |
Well we should still land this PR. This takes a step in the right direction for both the “help users avoid needing 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 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 |
Thanks for the extra info; I appreciate it. |
7678d90
to
f2bdcc5
Compare
That's correct. |
…tions Signed-off-by: Claudio W <cwunder@gnome.org>
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 |
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"? |
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". |
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. |
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.
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 |
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.
That's an interesting approach, definitely worth exploring.
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. |
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. |
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”? |
Yes there is. Did you miss this? |
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". |
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.
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. |
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.
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:
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. |
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? 🤔
Can agree. The current tab layout can be confusing; I misunderstood your previous statement as simply removing said options. My bad! |
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. |
I can check Sentry session replays to see how many folks are clicking on this. Allow me some time to collect the data. |
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:
![]() Q13: How do you get your Node.js executables? - Other
![]() Q9: Which version manager do you use? - Other
Q6: What is your primary use case for Node.js? - Other
|
Description
This PR does a few changes on our Downloads page such as:
Screenshots
Validation
All the download pages are working as expected
Related Issues
Relates to nodejs/package-maintenance#591