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:

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-alternatives/fedora-37-x86_64/04759584-npm/npm.spec

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