nodejs

nodejs@lists.fedoraproject.org

172 discussions

Packaging electron apps
by Gordon Messmer 15 Nov '25

15 Nov '25

Hello, people of nodejs. I would like to try to package an electron app. I have read packaging-guidelines/Node.js and nodejs-packaging-bundler. As best I understand it, Fedora allows packaging Node.js applications which will bundle all of the required modules from npm, as long as they are JS modules and not pre-built ELF binaries. The electron npm module includes pre-build ELF binaries, so in order to package an electron application, I would need to: 1. build an rpm providing the electron npm module (and possibly other packages for modules containing binaries) 2. prepare a package of the electron app, using the packaging bundler script 3. indicate a dependency on the electron module rpm package 4. strip the electron module from the node_modules bundle 5. replace the pre-built electron module with a symlink to the location of the electron module, provided by an rpm package Does that sound more or less correct?

4 5

nodejs bundler
by Gordon Messmer 04 Nov '25

04 Nov '25

I've made some progress on packaging an electron app and come across an interesting question... In order to create the node_module bundles, I need to have "husky" and "playwright" installed. I think playwright is needed for tests, but let's ignore that for a moment. The node_module bundles are uploaded as sources, which isn't automated. Is there a rule that would compel us to package the tools required to generate the bundles?

2 5

Re: Intel CET and gnu.properties
by Michael Dawson 02 Apr '25

02 Apr '25

Adding jan as he will have more insight into the flags used to build Node.js in fedora On Tue, Apr 1, 2025 at 12:54 PM Richard Lau <rlau(a)redhat.com> wrote: > On Tue, 1 Apr 2025 at 17:21, Tomas Juhasz <tjuhasz(a)redhat.com> wrote: > >> Hello, >> >> Lately I have been trying to make nodejs in fedora pass annocheck tests, >> which are a part of the gating process and I have runned into issues with >> the cf-protection >> <https://sourceware.org/annobin/annobin.html/Test-cf-protection.html> >> test which verifies that Intel's CET security feature is enabled. >> >> In all of the guides that I have found (including the linked annocheck >> guide) -fcf-protection flag is used to enable this feature, but in my >> testing the inclusion didn't enable it. >> >> Could you please help me find some information about the upstream >> utilization of this feature? >> I have noticed that in openssl and zstd >> <https://github.com/search?q=repo%3Anodejs%2Fnode%20.note.gnu.property&type=…> >> dependencies in the source code there is an implementation for the >> .gnu.properties instruction, but I don't know if it is supported by all >> components of nodejs. >> > > AFAIK upstream Node.js doesn't utilize this feature and if it has > benefitted at all from dependencies enabling it that is not by design. > > The gating test and enablement is likely to be something added by Fedora, > most likely the enablement is supposed to be inherited from > redhat-rpm-config: > https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#… > > -- > > Richard Lau > > Software Engineer, Runtimes > > Red Hat <https://www.redhat.com/> > > Email: rlau(a)redhat.com > > Mastodon: @richardlau@fosstodon.org <https://fosstodon.org/@richardlau> > <https://www.redhat.com/> > > -- > You received this message because you are subscribed to the Google Groups > "nodeshiftcore" group. > To view this discussion visit > https://groups.google.com/a/redhat.com/d/msgid/nodeshiftcore/CAOPr%3DUU_pyS… > <https://groups.google.com/a/redhat.com/d/msgid/nodeshiftcore/CAOPr%3DUU_pyS…> > . >

1 0

node-gyp and zwave-js-ui package reviews
by Michael Cronenworth 22 Nov '24

22 Nov '24

Hi all, I have opened package reviews for node-gyp and zwave-js-ui after polishing and testing. node-gyp: https://bugzilla.redhat.com/show_bug.cgi?id=2328456 zwave-js-ui: https://bugzilla.redhat.com/show_bug.cgi?id=2328457 Thanks, Michael

1 0

Packaging questions
by Michael Cronenworth 21 Nov '24

21 Nov '24

Hello, I am looking to package two applications that use Node.JS. This email will focus on one of the two. Z-Wave JS UI https://zwave-js.github.io/zwave-js-ui/ https://github.com/zwave-js/zwave-js-ui The application is, I believe, the only open source Z-Wave controller at this time. I had previously maintained the OpenZWave C++ library, but development on it has ceased. Z-Wave is a wireless protocol to control lights, switches, relays, or gather information for uses in home automation. I need to package Z-Wave JS UI to replace OpenZWave in use with the Domoticz application that I also package. I first read the Node.JS Packaging Guidelines, but initially struggled to know how to generate the bundled tarballs. Luckily I stumbled upon the tool to do that via nodejs-packaging-bundler. After generating an initial RPM spec file I generated an RPM but it fails to install. Would anyone be able to help? https://michael.cronenworth.com/RPMS/zwave-js-ui.spec https://michael.cronenworth.com/RPMS/zwave-js-ui-9.27.2-0.1.fc41.src.rpm dnf install ... Problem: conflicting requests - nothing provides libc++_shared.so needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc++_shared.so()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.musl-x86_64.so.1()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.so needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.so()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline [...] snipped out 10 more lines similar to the above... The second application is the Jellyfin web client. I currently package it via a bundled tarball generated with my own bash script using a local npm registry and using npm install. It builds offline, but I notice your packaging guidelines don't want to do it that way. I'll mold any knowledge gained with zwave-js-ui into jellyfin-web. Thanks, Michael

3 11

[Node.js] Stepping down as Node.js Maintainer in Fedora
by Stephen Gallagher 24 Jun '24

24 Jun '24

tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20 and nodejs16 packages in Fedora, effective June 30, 2024. I will continue to maintain libuv. It's been a hard decision to come to, but I think this is the correct decision for me. I've been effectively the sole maintainer of Node.js in Fedora for nearly a dozen years now (apparently, I landed the first official package in Fedora on Dec. 18, 2012). It has been a long, long road. I first picked up Node.js because it was being added as a new dependency on a package I maintained at the time: Review Board (a Django-base code-review application). When I looked into it, I discovered that others had tried - and failed - to package Node.js previously, but Fedora's rules at the time were *very* strict with regards to carrying bundled software and Node.js upstream at the time had a build-system that pretty much only allowed bundling. It took quite a bit of effort to work through that, but we got there in the end and I was able to deliver Node.js 0.8 as the very first version to ship as part of Fedora. It's been a wild ride ever since. For a long time, Fedora carried a single version of Node.js - whatever was the latest version destined for LTS status at the time that Fedora version would be released. Then, along came... Modularity. As you may know, I was heavily involved with the design of Modularity. Node.js in particular was something I viewed as a perfect consumer of this new packaging mechanism: it gave us the ability to ship all versions of Node.js in Fedora (not just the LTS ones) in a way that could be packaged in VMs and (new at the time) container images without needing to modify the way the applications were launched. Sadly, as you probably know, the implementation of Modularity fell short of its lofty goals and has largely been relegated to the dust-bin of history. When it became clear that Modules were going to be dropped from Fedora, I took on another big packaging exercise: DE-modularizing Node.js. Rather than go back to the "single Node.js version in Fedora" approach, I moved to a hybrid approach where we would have a single "system" version of Node.js LTS like in the older style, but we would also package the older (and newer!) LTS releases in a non-default arrangement, similar to how Python packages are delivered in Fedora. I've been doing it this way for a few years now, and while there have been some bumps in the road around major-release upgrades, it's been overall quite workable. Recently, the Node.js downstream maintainers made some additional improvements in Node.js 20 to unbundle some previously-precompiled WASM code into their own packages which build it properly. This is great! Unfortunately, it has introduced some new issues with the non-default version in the release (as many of you probably saw last week). We sorted this out by temporarily re-bundling the WASM in the non-default versions, but this is really a stop-gap solution. It's not a huge issue, but it took a big chunk out of my week to get that resolved and in doing it, I came to an important realization: I'm burnt out. I took a moment to think through it and realized that I don't actually *use* Node.js anywhere anymore. I've been maintaining it for so long that it's become a habit, but I'm not a real consumer of it. I've sent requests in the past to fedora-devel asking for comaintainers, but I've never actually had anyone step up, so I've just kept going. So that brings us to today and my decision to step down. It's been a wild ride, but I need to step away and focus on other things. I hope someone out there will pop up and take over for me. I'm perfectly happy to train someone on how I maintain the various versions, but my time as a maintainer is coming to an end. I'll keep things going for another month, but after that it becomes Someone Else's Problem. If you read this far, thanks for suffering through that rambling journey.

3 6

[Input Requested] Ending support for i686 builds of Node.js
by Stephen Gallagher 13 May '24

13 May '24

Upstream Node.js has not supported the i686 architecture officially since Node.js 10.x (released in 2018). As of Node.js 22, it appears that v8 will no longer build at all on that architecture. I'm not particularly willing to go to any great lengths to keep it alive on i686, but I want to know if there's anyone out there who is *desperately* in need of it in Fedora.

1 0

nodepick idea: allow using any node version as /usr/bin/node
by Honza Horak 09 Aug '23

09 Aug '23

The current implementation of alternative nodejs versions in a single Fedora (say 38), is this: * the main version (v18 in F38) ships /usr/bin/node * alternative versions ship only /usr/bin/node-XX Node modules packaged as RPM (e.g. nodejs-nodemon) then often include this hard dependency: Requires: /usr/bin/node Suppose I want to install only the alternative (non-default) version of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency. New proposal: use a concept that has proofed to work for ruby for longer time (except it's used for alternative implementations, rather than alternative versions, but the logic is similar) -- rubypick package ships /usr/bin/ruby that is actually a simple shell script. This script executes a particular binary of ruby based on a reasonable defaults, explicit parameters of environment variables. How it would work for node: The default nodejs version would ship a new sub-package called "nodepick", which would only ship a couple of shell scripts: /usr/bin/node, /usr/bin/npm, etc.. All nodejs versions (including the default one) would only ship versioned binaries /usr/bin/node-XX. The shell scripts would execute a particular versioned binary based on some reasonable logic (environment variables, default, available version)... From the RPM metadata perspective: There would need to be some soft dependency from nodepick -> node-XX, with priority for the default version (dnf honours priority by Suggests I think), and a hard dependency of each of the nodejs-XX -> nodepick. Thoughts? Honza

3 11

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
by Stephen Gallagher 12 Dec '22

12 Dec '22

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com> wrote: > > https://fedoraproject.org/wiki/Changes/NodejsRepackaging > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > We are reworking the Node.js packaging to make Node.js versions > available as parallel-installable packages. So, I'd like to give an update here and address potential issues that I discovered this week surrounding the upgrade path. First and most exciting: I've got the packaging work for Node.js 16 and Node.js 18 in good shape and it can be tried out by using my COPR at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ (`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems. Thanks to the input of folks on this thread, I've now put together parallel-installable versions, any of which can provide the /usr/bin/node by installing the appropriate `nodejsXX-interpreter-default` package. I've also got the dependencies established in such a way that a fresh install of `dnf install nodejs` on releases will result in automatically installing the latest stable version that was available at the Fedora release's Beta Freeze. (So for F38 it will be Node.js 18, for F39 it will be Node.js 20). On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the nodejs18 package will Obsolete the nodejs package. On upgrade of the same system to Fedora 39 later, it will continue on the Node.js 18 package. To switch to the newer version, the user will need to manually run `dnf swap nodejs18-interpreter-default nodejs20-interpreter-default). While this may seem unexpected behavior, I feel that it's better to maintain compatibility on upgrade with any applications in use rather than to force the upgrade unless the current version is going out of support. When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)? There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages: 1) Upgrading from either F36 or F37 will result in you getting Node.js 18. (This method is closest to how things worked prior to this Change, where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable) With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18. My questions to those brave souls who have read this far: 1) Which do you think is the best of the above options for upgrades to F38? 2) What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The nodejsXX package is no longer available upon upgrade (EOL). b. The user has nodejsXX installed as the default interpreter. The nodejsXX package is available but non-default upon upgrade. Thank you for reading to the end.

1 2

The Future of Node.js Packaging
by Stephen Gallagher 07 Sep '22

07 Sep '22

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-alternat…

5 17

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs