nodejs

nodejs@lists.fedoraproject.org

176 discussions

Electron has landed in Fedora Rawhide!
by Gordon Messmer 09 Sep '26

09 Sep '26

Rawhide now has Electron packages for x86_64 and aarch64. The upstream project does not build or test on ppc64le, but please contact me if you are interested in testing an experimental build and providing feedback. This package builds on the work done for chromium and cef packages. I want to thank the chromium package maintainers, and Neal for his assistance and review of the Electron package. Podman Desktop may be ready soon, it is merely waiting on reviews: Review Request: nodejs-oxc-parser - Fast JavaScript/TypeScript parser implemented in Rust <https://bugzilla.redhat.com/show_bug.cgi?id=2527707> Review Request: nodejs-oxc-resolver - ESM/CJS module resolution algorithm implemented in Rust <https://bugzilla.redhat.com/show_bug.cgi?id=2527708> Review Request: nodejs-tailwindcss-oxide - The Oxide engine for Tailwind CSS (native Node.js addon) <https://bugzilla.redhat.com/show_bug.cgi?id=2527709> Review Request: nodejs-lightningcss - An extremely fast CSS parser, transformer, bundler, and minifier <https://bugzilla.redhat.com/show_bug.cgi?id=2527710> Review Request: nodejs-rolldown - Fast Rust-based bundler for JavaScript with Rollup-compatible API <https://bugzilla.redhat.com/show_bug.cgi?id=2527711> Review Request: nodejs-vite - Next Generation NodeJS Frontend Tooling <https://bugzilla.redhat.com/show_bug.cgi?id=2527712> Review Request: podman-desktop - Manage Podman and other container engines from a single UI and tray <https://bugzilla.redhat.com/show_bug.cgi?id=2527713>

1 0

binary content in node_modules
by Gordon Messmer 28 Jun '26

28 Jun '26

OK, since the package review last weekend, I've been reading documentation, discussion threads, and running various experiments with LLMs. Among other things, because dependencies installed in node_modules don't necessarily have their own devDependencies installed, I think the only reasonable way to bundle dependencies is to not bundle any module that contains native binaries or Wasm files, and to require those modules to be installed as system modules. ( Ref: https://github.com/orgs/community/discussions/199880 ) To aid future package reviews of all types, I've suggested a change to fedora-review that will scan for native binaries in source archives: https://forge.fedoraproject.org/packaging/FedoraReview/pulls/553 Eventually I found "npm2rpm" which I think could reasonably replace nodejs-packaging-bundler and probably package "source.sh" scripts, if it were able to detect modules with binaries or Wasm and avoid bundling those. They'd need to be provided as system packages. I've offered such a feature to the developers of that project: https://github.com/theforeman/npm2rpm/pull/93 Additionally, I have another branch in my fork that adds more Fedora-specific changes to the spec template: https://github.com/gordonmessmer/npm2rpm/tree/fedora-spec Finally, I've written a draft update of the packaging guidelines, if npm2rpm replaces nodejs-packaging-bundler: https://forge.fedoraproject.org/packaging/guidelines/pulls/1553

1 0

binary content in node_modules
by Gordon Messmer 17 Jun '26

17 Jun '26

I've started a review of a nodejs package, and its node_modules include wasm and native binaries. I wanted to provide the packager with examples of packages that fix up their node_modules properly, but I'm actually a little confused by what I found. I picked nodejs-undici for reference, since it has a sources script: https://src.fedoraproject.org/rpms/nodejs-undici/blob/rawhide/f/undici-sour… That script removes wasm and rebundles the code, but only for the program itself. It's not stripping the node_modules directories of pre-built content. The prod directory is relatively small and I didn't see any pre-built binaries, but the dev directory contains "esbuild" ELF binaries. Shouldn't node_modules be stripped of this kind of content before uploading source? What package would you recommend as an reference example?

1 0

Packaging electron apps
by Gordon Messmer 19 May '26

19 May '26

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?

5 8

Unowned directory /usr/lib/node_modules
by Peter Oliver 11 Feb '26

11 Feb '26

In a package review (https://bugzilla.redhat.com/show_bug.cgi?id=2333620) it was observed that directory /usr/lib/node_modules/ is owned by package nodejs is Fedora 43 and earlier, whereas in Fedora 44 it is not. Do we know if this is intended? Do packages that create files under this directory need to own it themselves now, rather than depending on the package that does? If so, I think https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ needs updating to reflect that. -- Peter Oliver

3 3

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs