nodejs

nodejs@lists.fedoraproject.org

170 discussions

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

Fwd: [Bug 2075170] New: Review Request: npm - A JavaScript Package Manager
by Stephen Gallagher 27 Apr '22

27 Apr '22

I've just submitted a review request for separating out NPM into its own package (again). This is being done for a couple reasons: 1) To get rid of the ridiculous release field and take advantage of the %autorelease macro 2) I'm planning to rework how the nodejs packages work to make different versions parallel-installable (with the alternatives infrastructure owning /usr/bin/node). I want to keep NPM in a common location (/usr/lib/node_modules) so that it will work with whatever Node is in use. If someone on this list would be willing to perform the package review, I'd be appreciative. ---------- Forwarded message --------- From: <bugzilla(a)redhat.com> Date: Wed, Apr 13, 2022 at 2:27 PM Subject: [Bug 2075170] New: Review Request: npm - A JavaScript Package Manager To: <sgallagh(a)redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=2075170 Bug ID: 2075170 Summary: Review Request: npm - A JavaScript Package Manager Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody(a)fedoraproject.org Reporter: sgallagh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: package-review(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Spec URL: https://copr-dist-git.fedorainfracloud.org/cgit/sgallagh/npm/npm.git/plain/… SRPM URL: https://download.copr.fedorainfracloud.org/results/sgallagh/npm/srpm-builds… Description: npm is the world's largest software registry. Open source developers from every continent use npm to share and borrow packages, and many organizations use npm to manage private development as well. npm consists of three distinct components: * the website * the Command Line Interface (CLI) * the registry Use the [*website*](https://npmjs.com) to discover packages, set up profiles, and manage other aspects of your npm experience. For example, you can set up [organizations](https://www.npmjs.com/features) to manage access to public or private packages. The [*CLI*](https://docs.npmjs.com/cli/npm) runs from a terminal, and is how most developers interact with npm. The [*registry*](https://docs.npmjs.com/misc/registry) is a large public database of JavaScript software and the meta-information surrounding it. ## Use npm to . . . * Adapt packages of code for your apps, or incorporate packages as they are. * Download standalone tools you can use right away. * Run packages without downloading using [npx](https://www.npmjs.com/package/npx). * Share code with any npm user, anywhere. * Restrict code to specific developers. * Create organizations to coordinate package maintenance, coding, and developers. * Form virtual teams by using organizations. * Manage multiple versions of code and code dependencies. * Update applications easily when underlying code is updated. * Discover multiple ways to solve the same puzzle. * Find other developers who are working on similar problems and projects. Fedora Account System Username: sgallagh -- You are receiving this mail because: You reported the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2075170

3 6

Not updating Node to Mar. 17 security patches
by Stephen Gallagher 18 Mar '22

18 Mar '22

The patches provided apply only to the bundled OpenSSL sources that we do not use. The affected CVEs are addressed instead by the `openssl` package.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs