From Fedora Project Wiki

Node.js Repackaging


We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.


Current status

Detailed Description

We will be creating the packages nodejs-16, nodejs-18 and (in April) nodejs-20. These packages will be parallel-installable (with the exception of the -devel subpackages) and provide /usr/bin/node-$MAJOR. For each Fedora release, one source package will also generate a subpackage named nodejs-$MAJOR-unversioned-command, which will represent the default version of Node.js for that release

Node.js applications packaged in Fedora are recommended to modify their startup scripts to point at an appropriate /usr/bin/node-$MAJOR binary, to ensure compatibility even across release upgrades.


Mailing list thread

Neal Gompa raised the question of using a subpackage to own /usr/bin/node instead of using the alternatives subsystem, citing python as an example. My response was that the problem with this is that I want /usr/bin/node to always be available so long as any nodejs-$MAJOR version is installed. It also ensures that the node(1) manpage always matches the /usr/bin/node executable.

2022-09-14: After discussion on the list, this Change has been updated to drop the use of update-alternatives and replace it with nodejs-$MAJOR-unversioned-command. Additionally, we will be shipping an npm binary version-matched with each Node.js version.

Benefit to Fedora

User Benefits

  • Provides a simple way to have a different (or multiple) Node.js interpreters on their system. No dealing with Modularity.
  • Enables multiple versions of Node.js on the system (can test code against different versions without using containers)

Packager Benefits

  • No more modules to maintain.
  • Availability of multiple Node.js versions in the buildroot means that other nodejs-* packages can test against multiple supported options.


  • Proposal owners:

The packaging work is done and can be played with at today.

  • Other developers:

There should be no need to change any dependent packages, though packagers of Node.js software may wish to take advantage of the testing opportunities afforded.

2022-09-14: Packagers of Node applications will probably want to pin their application to a known-good Node.js release. This can be done by modifying the startup scripts to look for /usr/bin/node-$MAJOR explicitly.

  • Policies and guidelines: N/A (not needed for this Change)

We will be updating the Node.js Packaging Guidelines with the new best practices.

  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:


Upgrade/compatibility impact

Systems using the existing nodejs RPM package will be upgraded to the matching nodejs-$MAJOR version. Work is pending on how to migrate users of Modular Node.js to the new packages.

How To Test

User Experience

Done correctly, this should be handled entirely without the user's need to know about it.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


N/A (not a System Wide Change)

Release Notes

Multiple releases of Node.js may now be installed in parallel from the Fedora repositories.