tl;dr: I want to drop the Node.js modules and make Node available as parallel-installable interpreters (with /usr/bin/node managed by the alternatives subsystem).
For some time now, I've been looking at ways to improve our Node.js story to make it more maintainable. Modules seemed like a Good Idea at the Time™, but it has been difficult to maintain over the years. I'd like to propose that we abandon Modules as our strategy and instead move to parallel-installable packages. I've been quietly working on a proof-of-concept for this for a while now and it's finally in good-enough shape[1] that I can share it with you.
The change involves several key pieces:
1. The NPM package is no longer delivered as a subpackage of Node.js. We return to maintaining it as a separate package in Fedora.[2] 2. We ship the Node.js interpreter as `/usr/bin/node-$MAJOR` and use the alternatives[3] subsystem to maintain the `/usr/bin/node` symlink. 3. We configure the alternatives priority system such that newer versions of Node are preferred, with the exception of the version selected as the default for that Fedora release which will always be preferred over any other, if multiple versions are installed.
Some examples: On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs` would result in the `nodejs18` package being installed. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also `dnf install nodejs16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs16` would result in the `nodejs16` package being installed. This package would provide `/usr/bin/node` as a symlink to `/usr/bin/node-16`. A user could also install `nodejs-18`, which would provide the `/usr/bin/node-18` binary. Because Node.js v18 is the default for Fedora 37, this would result in the `/usr/bin/node` symlink being changed to point at `/usr/bin/node-18`.
On Fedora 37, the existing `nodejs` package is installed (F37's default Node is v18). A `dnf upgrade` would result in the `nodejs-18` package being installed, replacing `nodejs`. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also install `nodejs-16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
Some benefits to this approach: * With parallel-install, it becomes possible to run test suites against multiple major versions at the same time. For example, the NPM package will be able[4] to run its suite against v16 and v18 to ensure that it is compatible with both versions. * The complexities of the Module build would go away.
Some risks to this approach: * If Node.js dependencies like libuv or libnghttp2 make incompatible changes that cannot work with both older and newer Node.js releases, we will need to create compat- packages for them.
[1] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075170 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ [4] https://download.copr.fedorainfracloud.org/results/sgallagh/nodejs-alternati...
On Thu, Aug 25, 2022 at 11:48 AM Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr: I want to drop the Node.js modules and make Node available as parallel-installable interpreters (with /usr/bin/node managed by the alternatives subsystem).
For some time now, I've been looking at ways to improve our Node.js story to make it more maintainable. Modules seemed like a Good Idea at the Time™, but it has been difficult to maintain over the years. I'd like to propose that we abandon Modules as our strategy and instead move to parallel-installable packages. I've been quietly working on a proof-of-concept for this for a while now and it's finally in good-enough shape[1] that I can share it with you.
The change involves several key pieces:
- The NPM package is no longer delivered as a subpackage of Node.js.
We return to maintaining it as a separate package in Fedora.[2] 2. We ship the Node.js interpreter as `/usr/bin/node-$MAJOR` and use the alternatives[3] subsystem to maintain the `/usr/bin/node` symlink. 3. We configure the alternatives priority system such that newer versions of Node are preferred, with the exception of the version selected as the default for that Fedora release which will always be preferred over any other, if multiple versions are installed.
Some examples: On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs` would result in the `nodejs18` package being installed. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also `dnf install nodejs16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs16` would result in the `nodejs16` package being installed. This package would provide `/usr/bin/node` as a symlink to `/usr/bin/node-16`. A user could also install `nodejs-18`, which would provide the `/usr/bin/node-18` binary. Because Node.js v18 is the default for Fedora 37, this would result in the `/usr/bin/node` symlink being changed to point at `/usr/bin/node-18`.
On Fedora 37, the existing `nodejs` package is installed (F37's default Node is v18). A `dnf upgrade` would result in the `nodejs-18` package being installed, replacing `nodejs`. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also install `nodejs-16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
Some benefits to this approach:
- With parallel-install, it becomes possible to run test suites
against multiple major versions at the same time. For example, the NPM package will be able[4] to run its suite against v16 and v18 to ensure that it is compatible with both versions.
- The complexities of the Module build would go away.
Some risks to this approach:
- If Node.js dependencies like libuv or libnghttp2 make incompatible
changes that cannot work with both older and newer Node.js releases, we will need to create compat- packages for them.
Could we use a subpackage owning `/usr/bin/node` instead of alternatives, similar to Python?
On Thu, Aug 25, 2022 at 11:57 AM Neal Gompa ngompa13@gmail.com wrote: ...
Could we use a subpackage owning `/usr/bin/node` instead of alternatives, similar to Python?
That's somewhat different, since the canonical name for the Python 3 interpreter is /usr/bin/python3. The subpackage that owns /usr/bin/python is a special case used specifically to force old software to use Python 3.
I *could* switch from using the alternatives system to using the approach in https://src.fedoraproject.org/rpms/python3.11/blob/rawhide/f/python3.11.spec... but I'd actually prefer to see /usr/bin/node *always* available, even when only a non-default Node.js is installed (since that's where all Node software expects it to be).
On Thu, Aug 25, 2022 at 8:48 AM Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr: I want to drop the Node.js modules and make Node available as parallel-installable interpreters (with /usr/bin/node managed by the alternatives subsystem).
For some time now, I've been looking at ways to improve our Node.js story to make it more maintainable. Modules seemed like a Good Idea at the Time™, but it has been difficult to maintain over the years. I'd like to propose that we abandon Modules as our strategy and instead move to parallel-installable packages. I've been quietly working on a proof-of-concept for this for a while now and it's finally in good-enough shape[1] that I can share it with you.
The change involves several key pieces:
- The NPM package is no longer delivered as a subpackage of Node.js.
We return to maintaining it as a separate package in Fedora.[2] 2. We ship the Node.js interpreter as `/usr/bin/node-$MAJOR` and use the alternatives[3] subsystem to maintain the `/usr/bin/node` symlink. 3. We configure the alternatives priority system such that newer versions of Node are preferred, with the exception of the version selected as the default for that Fedora release which will always be preferred over any other, if multiple versions are installed.
Some examples: On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs` would result in the `nodejs18` package being installed. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also `dnf install nodejs16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs16` would result in the `nodejs16` package being installed. This package would provide `/usr/bin/node` as a symlink to `/usr/bin/node-16`. A user could also install `nodejs-18`, which would provide the `/usr/bin/node-18` binary. Because Node.js v18 is the default for Fedora 37, this would result in the `/usr/bin/node` symlink being changed to point at `/usr/bin/node-18`.
On Fedora 37, the existing `nodejs` package is installed (F37's default Node is v18). A `dnf upgrade` would result in the `nodejs-18` package being installed, replacing `nodejs`. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also install `nodejs-16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
Some benefits to this approach:
- With parallel-install, it becomes possible to run test suites
against multiple major versions at the same time. For example, the NPM package will be able[4] to run its suite against v16 and v18 to ensure that it is compatible with both versions.
- The complexities of the Module build would go away.
Some risks to this approach:
- If Node.js dependencies like libuv or libnghttp2 make incompatible
changes that cannot work with both older and newer Node.js releases, we will need to create compat- packages for them.
[1] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075170 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ [4] https://download.copr.fedorainfracloud.org/results/sgallagh/nodejs-alternati...
You've already answered everything I was going to ask about this. I just want to say I like this plan.
Troy
I'd be interested in some of the scenarios above, but where a version of Node.js higher than the default has been installed.
For example I install nodejs v20 (F37's default Node is v18, but v20 is now available). I then run `dnf upgrade` what happens?
Overall what you describe seems more familiar to me in terms of how to manage versions/multiple copies of a component on linux.
One of question is if it would be possible to warn people or require a --force flag if people install EOL versions, even if it is the default for the Fedora version. I understand we always want to allow people to stick to the version that came with a Fedora/RHEL version but I think we could do more to help them avoid accidentally use an EOL verion.
On Thu, Aug 25, 2022 at 12:39 PM Troy Dawson tdawson@redhat.com wrote:
On Thu, Aug 25, 2022 at 8:48 AM Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr: I want to drop the Node.js modules and make Node available as parallel-installable interpreters (with /usr/bin/node managed by the alternatives subsystem).
For some time now, I've been looking at ways to improve our Node.js story to make it more maintainable. Modules seemed like a Good Idea at the Time™, but it has been difficult to maintain over the years. I'd like to propose that we abandon Modules as our strategy and instead move to parallel-installable packages. I've been quietly working on a proof-of-concept for this for a while now and it's finally in good-enough shape[1] that I can share it with you.
The change involves several key pieces:
- The NPM package is no longer delivered as a subpackage of Node.js.
We return to maintaining it as a separate package in Fedora.[2] 2. We ship the Node.js interpreter as `/usr/bin/node-$MAJOR` and use the alternatives[3] subsystem to maintain the `/usr/bin/node` symlink. 3. We configure the alternatives priority system such that newer versions of Node are preferred, with the exception of the version selected as the default for that Fedora release which will always be preferred over any other, if multiple versions are installed.
Some examples: On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs` would result in the `nodejs18` package being installed. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also `dnf install nodejs16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs16` would result in the `nodejs16` package being installed. This package would provide `/usr/bin/node` as a symlink to `/usr/bin/node-16`. A user could also install `nodejs-18`, which would provide the `/usr/bin/node-18` binary. Because Node.js v18 is the default for Fedora 37, this would result in the `/usr/bin/node` symlink being changed to point at `/usr/bin/node-18`.
On Fedora 37, the existing `nodejs` package is installed (F37's default Node is v18). A `dnf upgrade` would result in the `nodejs-18` package being installed, replacing `nodejs`. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also install `nodejs-16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`.
Some benefits to this approach:
- With parallel-install, it becomes possible to run test suites
against multiple major versions at the same time. For example, the NPM package will be able[4] to run its suite against v16 and v18 to ensure that it is compatible with both versions.
- The complexities of the Module build would go away.
Some risks to this approach:
- If Node.js dependencies like libuv or libnghttp2 make incompatible
changes that cannot work with both older and newer Node.js releases, we will need to create compat- packages for them.
[1] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075170 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ [4] https://download.copr.fedorainfracloud.org/results/sgallagh/nodejs-alternati...
You've already answered everything I was going to ask about this. I just want to say I like this plan.
Troy
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Aug 26, 2022 at 2:27 PM Michael Dawson midawson@redhat.com wrote:
I'd be interested in some of the scenarios above, but where a version of Node.js higher than the default has been installed.
For example I install nodejs v20 (F37's default Node is v18, but v20 is now available). I then run `dnf upgrade` what happens?
Is Node.js v18 also installed on the system? If so, then /usr/bin/node would be v18 and both packages (nodejs18 and nodejs20) would be upgraded to the latest available package version.
If *only* Node.js v20 is installed on the system, then /usr/bin/node would be v20 and only v20 will be upgraded.
Overall what you describe seems more familiar to me in terms of how to manage versions/multiple copies of a component on linux.
One of question is if it would be possible to warn people or require a --force flag if people install EOL versions, even if it is the default for the Fedora version. I understand we always want to allow people to stick to the version that came with a Fedora/RHEL version but I think we could do more to help them avoid accidentally use an EOL verion.
There's really no easy way to prevent installation of an EOL version. It's just not a feature of the package manager.
That said, my plan is to deal with this mostly via policy: the Node.js packaging policy would be amended to say that we only ship Node.js versions in a Fedora release that remain fully supported until that Fedora release's expected End-of-Life date.
For a more concrete example, let's take a look at the expected lifecycle dates for Fedora 37, 38 and 39 and compare them to the lifecycle dates for Node.js 14, 16, 18, 20 and 22.
Fedora 37: Oct 2022 - Nov 2023 Fedora 38: May 2023 - Jun 2024 Fedora 39: Oct 2023 - Nov 2024
Node 14: Apr 2020 - Apr 2023 Node 16: Apr 2021 - Sep 2023 (Special, because of OpenSSL)[*] Node 18: Apr 2022 - Apr 2025 Node 20: Apr 2023 - Apr 2026 Node 22: Apr 2024 - Apr 2027 (Assumed) Node 24: Apr 2025 - Apr 2026 (Assumed)
In Fedora 37, we would be able to ship Node.js 16[*], 18 and 20 (which releases Apr 2023). We would not ship Node.js v14 because its EOL date is earlier than Fedora 37's. We wouldn't ship Node.js 22 in Fedora 37 because it will be released after Fedora 37's EOL. The default would be v18.
In Fedora 38, we'd be shipping Node.js 18, 20, and 22, though Node v22 will only be supported for a few months. It's not any extra effort to build it for an extra Fedora release, though. The default would be v20.
In Fedora 39, we'd again be shipping 18, 20 and 22. Node v24 will be released after the Fedora EOL. The default would be v20.
[*] The period between Sep 2023 and Nov 2023 is short enough that we should probably make an exception and ship v16. This is the only situation in Fedora where we might be shipping an unsupported version of Node.js.
I can see how that is possible for Fedora but the same won't be true for RHEL
On Fri, Aug 26, 2022 at 3:20 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, Aug 26, 2022 at 2:27 PM Michael Dawson midawson@redhat.com wrote:
I'd be interested in some of the scenarios above, but where a version of
Node.js higher than the default has been installed.
For example I install nodejs v20 (F37's default Node is v18, but v20 is
now available). I then run `dnf upgrade` what happens?
Is Node.js v18 also installed on the system? If so, then /usr/bin/node would be v18 and both packages (nodejs18 and nodejs20) would be upgraded to the latest available package version.
If *only* Node.js v20 is installed on the system, then /usr/bin/node would be v20 and only v20 will be upgraded.
Overall what you describe seems more familiar to me in terms of how to
manage versions/multiple copies of a component on linux.
One of question is if it would be possible to warn people or require a
--force flag if people install EOL versions, even if it is the default for the Fedora version. I understand we always want to allow people to stick to the version that came with a Fedora/RHEL version but I think we could do more to help them avoid accidentally use an EOL verion.
There's really no easy way to prevent installation of an EOL version. It's just not a feature of the package manager.
That said, my plan is to deal with this mostly via policy: the Node.js packaging policy would be amended to say that we only ship Node.js versions in a Fedora release that remain fully supported until that Fedora release's expected End-of-Life date.
For a more concrete example, let's take a look at the expected lifecycle dates for Fedora 37, 38 and 39 and compare them to the lifecycle dates for Node.js 14, 16, 18, 20 and 22.
Fedora 37: Oct 2022 - Nov 2023 Fedora 38: May 2023 - Jun 2024 Fedora 39: Oct 2023 - Nov 2024
Node 14: Apr 2020 - Apr 2023 Node 16: Apr 2021 - Sep 2023 (Special, because of OpenSSL)[*] Node 18: Apr 2022 - Apr 2025 Node 20: Apr 2023 - Apr 2026 Node 22: Apr 2024 - Apr 2027 (Assumed) Node 24: Apr 2025 - Apr 2026 (Assumed)
In Fedora 37, we would be able to ship Node.js 16[*], 18 and 20 (which releases Apr 2023). We would not ship Node.js v14 because its EOL date is earlier than Fedora 37's. We wouldn't ship Node.js 22 in Fedora 37 because it will be released after Fedora 37's EOL. The default would be v18.
In Fedora 38, we'd be shipping Node.js 18, 20, and 22, though Node v22 will only be supported for a few months. It's not any extra effort to build it for an extra Fedora release, though. The default would be v20.
In Fedora 39, we'd again be shipping 18, 20 and 22. Node v24 will be released after the Fedora EOL. The default would be v20.
[*] The period between Sep 2023 and Nov 2023 is short enough that we should probably make an exception and ship v16. This is the only situation in Fedora where we might be shipping an unsupported version of Node.js. _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Aug 26, 2022 at 3:48 PM Michael Dawson midawson@redhat.com wrote:
I can see how that is possible for Fedora but the same won't be true for RHEL
Right, and RHEL has historically handled this through documentation and support policy rather than via preventing installation. The packages remain in the distribution and can be installed without any extra steps, but customers will receive no support for them and are on their own with regards to the risks (which are documented on the support portal and in many other places).
I wonder, should there also be /usr/bin/npm-16 and /usr/bin/npm-18, ala /usr/bin/pip3.7, /usr/bin/pip3.8, /usr/bin/pydoc3.7, ... ?
Right now, an 'npm' command always runs in whatever version is set as /usr/bin/node, which makes it difficult to use a non-default version of /usr/bin/node-* to install packages — which seems like it could be useful for testing purposes.
Or is there some way I'm missing, that the single /usr/bin/node can be used with different versions?
Hmm. `node-18 /usr/bin/npm install` seems to work (if the default is node-16)... but that feels clunky.
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. ferdnyc@gmail.com wrote:
I wonder, should there also be /usr/bin/npm-16 and /usr/bin/npm-18, ala /usr/bin/pip3.7, /usr/bin/pip3.8, /usr/bin/pydoc3.7, ... ?
Right now, an 'npm' command always runs in whatever version is set as /usr/bin/node, which makes it difficult to use a non-default version of /usr/bin/node-* to install packages — which seems like it could be useful for testing purposes.
Or is there some way I'm missing, that the single /usr/bin/node can be used with different versions?
Hmm. `node-18 /usr/bin/npm install` seems to work (if the default is node-16)... but that feels clunky. _____________________________
I don’t think there’s really any value in using a different version of Node.js than the default to run npm, barring an exceptionally serious bug. Can you provide a specific example where it would matter?
I think there’s more value in making sure that the latest npm is compatible with the older runtimes and standardize on that. I’ve got the npm package’s self-test suite running against all the node versions in the %check section to catch potential regressions.
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. <ferdnyc(a)gmail.com> wrote:
I don’t think there’s really any value in using a different version of Node.js than the default to run npm, barring an exceptionally serious bug. Can you provide a specific example where it would matter?
Not a definitive one, no. My main concern would be packages that might install a different version, or install themselves differently (different dependencies pulled in, etc.), based on the node version they're being installed with — or is that not something npm supports?
On Tue, Sep 6, 2022 at 7:22 PM Frank R Dana Jr. ferdnyc@gmail.com wrote:
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. <ferdnyc(a)gmail.com> wrote:
I don’t think there’s really any value in using a different version of Node.js than the default to run npm, barring an exceptionally serious bug. Can you provide a specific example where it would matter?
Not a definitive one, no. My main concern would be packages that might install a different version, or install themselves differently (different dependencies pulled in, etc.), based on the node version they're being installed with — or is that not something npm supports?
It does. It can definitely do that, especially with nodejs extension modules.
By
I think there’s more value in making sure that the latest npm is
compatible with the older runtimes and standardize on that.
Do you mean use that by default for all versions of Node.js? That would be different than the general ecosystem and the most/best tested combinations.
On Tue, Sep 6, 2022 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 6, 2022 at 7:22 PM Frank R Dana Jr. ferdnyc@gmail.com wrote:
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. <ferdnyc(a)gmail.com>
wrote:
I don’t think there’s really any value in using a different version of Node.js than the default to run npm, barring an exceptionally serious
bug.
Can you provide a specific example where it would matter?
Not a definitive one, no. My main concern would be packages that might
install a different version, or install themselves differently (different dependencies pulled in, etc.), based on the node version they're being installed with — or is that not something npm supports?
It does. It can definitely do that, especially with nodejs extension modules.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Sep 7, 2022 at 9:31 AM Michael Dawson midawson@redhat.com wrote:
By
I think there’s more value in making sure that the latest npm is compatible with the older runtimes and standardize on that.
Do you mean use that by default for all versions of Node.js? That would be different than the general ecosystem and the most/best tested combinations.
Would that differ from the general ecosystem? The npm command itself tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
On Tue, Sep 6, 2022 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 6, 2022 at 7:22 PM Frank R Dana Jr. ferdnyc@gmail.com wrote:
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. <ferdnyc(a)gmail.com> wrote:
I don’t think there’s really any value in using a different version of Node.js than the default to run npm, barring an exceptionally serious bug. Can you provide a specific example where it would matter?
Not a definitive one, no. My main concern would be packages that might install a different version, or install themselves differently (different dependencies pulled in, etc.), based on the node version they're being installed with — or is that not something npm supports?
It does. It can definitely do that, especially with nodejs extension modules.
I expect in the overwhelming majority of cases, people will only install one Node.js version into the system, and therefore the alternatives system will take care of this. In those other cases, is `/usr/bin/node-18 /usr/bin/npm` particularly onerous? Is `/usr/bin/npm-18` any better (it could be confusing)? I don't think there's any accurate way to auto-detect which Node version you intended to run against if there is more than one on the system. So *somehow* the user would need to specify it explicitly. I'm open to suggestions on how this could be done.
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
On Wed, Sep 7, 2022 at 9:41 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:31 AM Michael Dawson midawson@redhat.com wrote:
By
I think there’s more value in making sure that the latest npm is
compatible with the older runtimes and standardize on that.
Do you mean use that by default for all versions of Node.js? That would
be different than the general ecosystem and the most/best tested combinations.
Would that differ from the general ecosystem? The npm command itself tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
On Tue, Sep 6, 2022 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 6, 2022 at 7:22 PM Frank R Dana Jr. ferdnyc@gmail.com
wrote:
On Tue, Sep 6, 2022 at 5:03 PM Frank R Dana Jr. <ferdnyc(a)
gmail.com> wrote:
I don’t think there’s really any value in using a different version
of
Node.js than the default to run npm, barring an exceptionally
serious bug.
Can you provide a specific example where it would matter?
Not a definitive one, no. My main concern would be packages that
might install a different version, or install themselves differently (different dependencies pulled in, etc.), based on the node version they're being installed with — or is that not something npm supports?
It does. It can definitely do that, especially with nodejs extension
modules.
I expect in the overwhelming majority of cases, people will only install one Node.js version into the system, and therefore the alternatives system will take care of this. In those other cases, is `/usr/bin/node-18 /usr/bin/npm` particularly onerous? Is `/usr/bin/npm-18` any better (it could be confusing)? I don't think there's any accurate way to auto-detect which Node version you intended to run against if there is more than one on the system. So *somehow* the user would need to specify it explicitly. I'm open to suggestions on how this could be done. _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the
version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
And 3 more for "stick with whatever ships with the version of node they're using"
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson midawson@redhat.com wrote:
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the
version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs@lists.fedoraproject.org
-
Frank R Dana Jr. -
Michael Dawson -
Neal Gompa -
Stephen Gallagher -
Troy Dawson