Add guidelines for using different nodejs versions #1561

Open
jstanek wants to merge 1 commit from jstanek/packaging-guidelines:nodejs-metapackage into main
Member

This is aiming to summarize how we envision the various packaged nodejs streams should be used once the metapackage change lands.

It is expected that the section might grow or be adjusted as we gather feedback from the wider user base after the change lands; this is intended to be a usable starting point.

This is aiming to summarize how we envision the various packaged nodejs streams should be used once the [metapackage change](https://fedoraproject.org/wiki/Changes/NodeJSMetapackages) lands. It is expected that the section might grow or be adjusted as we gather feedback from the wider user base after the change lands; this is intended to be a usable starting point.
churchyard left a comment

I provided a couple of nitpicks.

Could you please also provide some runtime dependency examples? I worry, for example, about how I should deal with nodejs shebangs.

I provided a couple of nitpicks. Could you please also provide some runtime dependency examples? I worry, for example, about how I should deal with nodejs shebangs.
@ -16,3 +16,3 @@
* The name of a Node.js extension/library package must start with _nodejs-_ then the upstream name or name used in the npm registry. For example: _nodejs-foomodule_. While it is uncommon for a package's name to contain _node_, if it does, you should still add the nodejs prefix. For instance, the npm registry contains a _uuid_ and a _node-uuid_ module, which would need to be named _nodejs-uuid_ and _nodejs-node-uuid_, respectively.
== BuildRequires
== Managing versioned stream dependencies
Owner

I'm not keen on the usage of "stream" in this context. RHEL uses that vocabulary. Modularity did. But I don't think we use it elsewhere in the packaging guidelines.

I'm not keen on the usage of "stream" in this context. RHEL uses that vocabulary. Modularity did. But I don't think we use it elsewhere in the packaging guidelines.
Author
Member

Yeah, since I also think of this in terms of the distributions that are based on Fedora, the "stream" comes to me naturally; but I'm open to changes. Suggestions? „Managing dependencies to specific nodejs versions"?

Yeah, since I also think of this in terms of the distributions that are based on Fedora, the "stream" comes to me naturally; but I'm open to changes. Suggestions? „Managing dependencies to specific nodejs versions"?
jstanek marked this conversation as resolved
@ -19,0 +18,4 @@
== Managing versioned stream dependencies
In Fedora, multiple Node.js versions are generally available at any given time.
You should take that into an account when specifying dependencies for your package.
Owner

into account or into consideration . Either way, drop the an, please. (For some reason, I don't see a way to add a direct change suggestion here :/ )

_into account_ or _into consideration_ . Either way, drop the _an_, please. (For some reason, I don't see a way to add a direct change suggestion here :/ )
jstanek marked this conversation as resolved
@ -19,0 +20,4 @@
In Fedora, multiple Node.js versions are generally available at any given time.
You should take that into an account when specifying dependencies for your package.
If your package could be used with any currently supported major version of Node.js,
Owner

This seems problematic. How do I recognize that this is the case? Also, for rawhide, does this mean any version of Node.js supported in the 18-month future, not only currently?

This seems problematic. How do I *recognize* that this is the case? Also, for rawhide, does this mean any version of Node.js supported in the 18-month future, not only currently?
Author
Member

How do I recognize that this is the case?

That is good question, and unfortunately I don't have enough javascript packaging experience to be able to answer this with certainty. My guess would be to take a look at the engines.node field in package.json file and be guided by that. But ideally test that.

Also, for rawhide, does this mean any version of Node.js supported in the 18-month future, not only currently?

Now that I think about it, yes. We will be changing what the default/recommended version will be in rawhide periodically, and the package should ideally survive that without a rebuild.


The idea of this paragraph is to avoid overspecification of the dependencies. For packages that are simple enough and do not depend on the latest-greatest new features of Node, and can be packaged with anything, I would prefer to not have to specify e.g. Buildrequires: nodejs22-devel and then having to rebuild it when nodejs22 will become EOL.

How to actually tell this is the case will require some testing on the packager side, most likely.

> How do I recognize that this is the case? That is good question, and unfortunately I don't have enough javascript packaging experience to be able to answer this with certainty. My guess would be to take a look at the `engines.node` field in `package.json` file and be guided by that. But ideally test that. > Also, for rawhide, does this mean any version of Node.js supported in the 18-month future, not only currently? Now that I think about it, yes. We will be changing what the default/recommended version will be in rawhide periodically, and the package should ideally survive that without a rebuild. --- The idea of this paragraph is to avoid overspecification of the dependencies. For packages that are simple enough and do not depend on the latest-greatest new features of Node, and can be packaged with anything, I would prefer to not have to specify e.g. `Buildrequires: nodejs22-devel` and then having to rebuild it when `nodejs22` will become EOL. How to actually tell this is the case will require some testing on the packager side, most likely.
jstanek marked this conversation as resolved
@ -19,0 +21,4 @@
You should take that into an account when specifying dependencies for your package.
If your package could be used with any currently supported major version of Node.js,
it is recommended to use the generic `+nodejs+` package and/or it's subpackages.
Owner

Please replace is recommended with a guideline (e.g. you SHOULD or the package SHOULD).

Please replace use with an actual packaging term (e.g. require).

Please replace *is recommended* with a guideline (e.g. _you SHOULD_ or _the package SHOULD_). Please replace *use* with an actual packaging term (e.g. *require*).
jstanek marked this conversation as resolved
@ -19,0 +22,4 @@
If your package could be used with any currently supported major version of Node.js,
it is recommended to use the generic `+nodejs+` package and/or it's subpackages.
This will provide one of the supported major versions;
Owner

provide is also hard to parse here. This will ensure the package is installable with... or something along those lines sounds better to me.

*provide* is also hard to parse here. *This will ensure the package is installable with...* or something along those lines sounds better to me.
jstanek marked this conversation as resolved
@ -19,0 +23,4 @@
If your package could be used with any currently supported major version of Node.js,
it is recommended to use the generic `+nodejs+` package and/or it's subpackages.
This will provide one of the supported major versions;
however, the exact version might be different in different Fedora versions.
Owner

Or depending on other installed packages?

Or depending on other installed packages?
Author
Member

Not really. Require: nodejs or BuildRequire: nodejs will pull the same version in every installation of given Fedora version (e.g. in current rawhide, nodejs requires nodejs22). But that requirement will be changing, usually in rawhide somewhere safe-ish between branching of new releases, so in time it may look similarly to this:

  • F44: nodejs requires nodejs22
  • F45: nodejs requires nodejs24
  • F46: nodejs requires nodejs26

So if you build the same package across multiple releases, you may be building against different nodejs version in each of them.

Not really. `Require: nodejs` or `BuildRequire: nodejs` will pull the same version in every installation of given Fedora version (e.g. in current rawhide, `nodejs` requires `nodejs22`). But that requirement will be changing, usually in rawhide somewhere safe-ish between branching of new releases, so in time it may look similarly to this: * F44: `nodejs` requires `nodejs22` * F45: `nodejs` requires `nodejs24` * F46: `nodejs` requires `nodejs26` So if you build the same package across multiple releases, you may be building against different nodejs version in each of them.
Owner

Oh, I assumed the dependency could be satisfied with any nodejs version. That is no longer the case?

Oh, I assumed the dependency could be satisfied with any nodejs version. That is no longer the case?
Author
Member

Technically speaking, no, it's no longer the case. In case you specify just BuildRequires: nodejs, you are handing control over which major version you'll get to the maintainers of that package (us). We want to have more control over which package would be "selected" by that requirement.

If all of the streams would just Provides: nodejs = <version>, then the choice would be up to DNF, and generally speaking always the latest available stream. That is not always what we want.

Technically speaking, no, it's no longer the case. In case you specify just `BuildRequires: nodejs`, you are handing control over which major version you'll get to the maintainers of that package (us). We want to have more control over which package would be "selected" by that requirement. If all of the streams would just `Provides: nodejs = <version>`, then the choice would be up to DNF, and generally speaking always the latest available stream. That is not always what we want.
@ -19,0 +25,4 @@
This will provide one of the supported major versions;
however, the exact version might be different in different Fedora versions.
If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),
Owner

Where can I find the list of supported Node.js versions in the current Fedora release?

EDIT: I see this is answered later in the text. How can we make that more obvious here?

Where can I find the list of supported Node.js versions in the current Fedora release? EDIT: I see this is answered later in the text. How can we make that more obvious here?
Author
Member

I'll try to think about how can I move things around here.

I'll try to think about how can I move things around here.
jstanek marked this conversation as resolved
@ -19,0 +26,4 @@
however, the exact version might be different in different Fedora versions.
If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),
you should pick one of them and request it specifically.
Owner

request -> require

request -> require
jstanek marked this conversation as resolved
@ -23,6 +37,22 @@ To build a package that is a nodejs module, bundles or uses nodejs modules, or n
BuildRequires: nodejs-devel
....
If the package only builds against specific version(s) of Node.js, request the specific version:
Owner

I'd rather split this into two sentences:

If the package only builds against a specific version of Node.js, BuildRequire it explicitly. If it builds against multiple specific versions (but not all), pick one.

I'd rather split this into two sentences: > If the package only builds against a specific version of Node.js, BuildRequire it explicitly. If it builds against multiple specific versions (but not all), pick one.
jstanek marked this conversation as resolved
@ -26,0 +47,4 @@
For example:
....
$ sudo dnf --repo=rawhide repoquery --whatprovides 'alternative-for(nodejs-devel)'
Owner

No need for sudo

No need for sudo
jstanek marked this conversation as resolved
Author
Member

@churchyard wrote in #1561 (comment):

Could you please also provide some runtime dependency examples? I worry, for example, about how I should deal with nodejs shebangs.

Runtime is a bit of different beast, and the problem space is unfortunately still open. But I'll will add something.

Shebangs could (and probably) should be adjusted if you need the specific version at runtime, but that is not something we have any support (scripts, macros) for now. So I guess in the meantime, I'll add something to the effect of „You MUST Require: nodejsXY-bin if you need a specific version at runtime. This will unfortunately make your package incompatible with any other package that requires different nodejsXY version.“ Perhaps invitation for collaboration will also not go amiss there.

@churchyard wrote in https://forge.fedoraproject.org/packaging/guidelines/pulls/1561#issuecomment-1073115: > Could you please also provide some runtime dependency examples? I worry, for example, about how I should deal with nodejs shebangs. Runtime is a bit of different beast, and the problem space is unfortunately still open. But I'll will add something. Shebangs could (and probably) should be adjusted if you need the specific version at runtime, but that is not something we have any support (scripts, macros) for now. So I guess in the meantime, I'll add something to the effect of „You MUST `Require: nodejsXY-bin` if you need a specific version at runtime. This will unfortunately make your package incompatible with any other package that requires different nodejsXY version.“ Perhaps invitation for collaboration will also not go amiss there.
- Moved text around a bit to be hopefully more readable
- Add few paragraphs on handling runtime dependencies
- Fixed typos and stylistic errors
jstanek changed title from Add guidelines for using different nodejs versions to WIP: Add guidelines for using different nodejs versions 2026-08-05 14:20:32 +00:00
Author
Member

@churchyard I've attempted to incorporate your feedback, and expanded the text with (hopefully) answers to your questions. Let me know what you think of the next iterations.

I plan to just add commits new commits as feedback comes, and I'll squash them before merging the final version. Hence the WIP prefix in order to not merge the messy history.

@churchyard I've attempted to incorporate your feedback, and expanded the text with (hopefully) answers to your questions. Let me know what you think of the next iterations. I plan to just add commits new commits as feedback comes, and I'll squash them before merging the final version. Hence the WIP prefix in order to not merge the messy history.
jstanek force-pushed nodejs-metapackage from e7cc02f337 to 761008346c 2026-08-05 14:32:17 +00:00 Compare
@ -19,0 +44,4 @@
If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),
you should pick one of them and require it specifically.
Use the `+nodejs{XY}+` package (e.g. `+nodejs24+` for Node.js v24.x.y) for this.
Member

At this place, I would highly encourage to work with upstream of such package to relax the restriction. Also, it would be good idea to document why the restriction applies so it is easier to revisit.

At this place, I would highly encourage to work with upstream of such package to relax the restriction. Also, it would be good idea to document why the restriction applies so it is easier to revisit.
@ -23,6 +54,39 @@ To build a package that is a nodejs module, bundles or uses nodejs modules, or n
BuildRequires: nodejs-devel
....
If the package only builds against a specific version of Node.js, BuildRequire it explicitly.
Member

This could somehow refer to the comment above.

This could somehow refer to the comment above.
@ -26,0 +71,4 @@
....
# This package requires /usr/bin/node to launch Node.js v24.x or any newer
Requires: alternative-for(nodejs-bin) >= 24
Member

Would e.g. Recommends be an option here? Of course the question is if it is better option to have something possibly broken or to have e.g. broken update (maybe preventing system updates and therefore security)

Would e.g. `Recommends` be an option here? Of course the question is if it is better option to have something possibly broken or to have e.g. broken update (maybe preventing system updates and therefore security)
Author
Member

I don't think so. The entire point of this Requires: line is to specify "I absolutely need at least Node.js 24 as /usr/bin/node or I will not work". With Recommends:, that would be only a suggestion; and if you don't really need a specific version, this requirement should not be there at all.

I don't think so. The entire point of this `Requires:` line is to specify "I absolutely need at least Node.js 24 as `/usr/bin/node` or I will not work". With `Recommends:`, that would be only a suggestion; and if you don't really need a specific version, this requirement should not be there at all.
Author
Member

No further feedback in a week; marking this as ready to be merged.

No further feedback in a week; marking this as ready to be merged.
jstanek force-pushed nodejs-metapackage from e0f255a0cf to db2c28b047 2026-08-27 10:11:46 +00:00 Compare
jstanek changed title from WIP: Add guidelines for using different nodejs versions to Add guidelines for using different nodejs versions 2026-08-27 10:14:04 +00:00
jstanek force-pushed nodejs-metapackage from db2c28b047 to 89684f5787 2026-08-27 13:09:01 +00:00 Compare
Author
Member

Squashed "incorporating feedback" commits to the original one.

Squashed "incorporating feedback" commits to the original one.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u nodejs-metapackage:jstanek-nodejs-metapackage
git switch jstanek-nodejs-metapackage

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff jstanek-nodejs-metapackage
git switch jstanek-nodejs-metapackage
git rebase main
git switch main
git merge --ff-only jstanek-nodejs-metapackage
git switch jstanek-nodejs-metapackage
git rebase main
git switch main
git merge --no-ff jstanek-nodejs-metapackage
git switch main
git merge --squash jstanek-nodejs-metapackage
git switch main
git merge --ff-only jstanek-nodejs-metapackage
git switch main
git merge jstanek-nodejs-metapackage
git push origin main
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
packaging/guidelines!1561
No description provided.