This is why I have concluded that the current iteration of the NodeJS packaging guidelines is fundamentally unworkable. They prescribe bundling all dependencies, and they recommend the nodejs-packaging-bundler script, but then it becomes the packager’s responsibility to review the resulting huge pile of code for license issues, bundled fonts, pre-compiled executables, generated code without original sources, and so on, and to re-review it on every update as the dependency tree shifts.

Even the example in the actual NodeJS guidelines, https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_example_spec, would have 33 pre-compiled *.min.js files in its dev-dependency bundle. Each of these is not only minified, but may be transpiled from other languages and may bundle arbitrary other libraries and content. The example’s dev-dependency bundle also contains pre-compiled binaries for Windows and MacOS and a couple of (tiny) bundled TrueType fonts in data URLs of the form "url(data:application/x-font-ttf;…)". The example’s production bundle looks better, although I haven’t reviewed it closely, but problematic files could creep in any time it needs to be regenerated. To put some numbers on the review burden of the bundled approach, the example in the guidelines has 3973 files totaling 5+ MB in its prod bundle, and 14355 files totaling 43+ MB in its dev bundle.

Worse, when issues are found in the dependencies, it is often nearly impossible to fix them, because the published NPM packages often aren’t really the original sources. This is true to a degree in other ecosystems like Python and Rust, but NPM packages are much more likely to do heavyweight “build” processes during publication. In many cases, one would have to go back and work from the original upstream VCS to make changes, and then you are likely to need that package’s dev-dependencies, and so on until you are constantly patching and re-packaging a big chunk of the NPM ecosystem for every package and every update. This is impractical enough that I have never seen anyone actually attempt to meaningfully patch dependencies in a bundle. Even if they did, because everyone is supposed to bundle everything, none of the work on massive but difficult dependencies like esbuild or rollup could be shared, and everyone would have to reinvent the wheel all of the time.

In practice, all of this pushes people into one of two approaches: either shove all of the ugly details under the rug in the name of practicality, avoid looking too closely at the dependency bundle, and plead ignorance; or swear off NodeJS packaging entirely and avoid anything that involves it. I’m not sure what to suggest as a solution. The sheer number of NodeJS packages and the “web culture” associated with them makes it a particularly difficult ecosystem to work with, and I concede that we weren’t keeping up before the guidelines changed to prescribe bundling, either.


On 18/06/2026 21:11, Gordon Messmer wrote:
I've started a review of a nodejs package, and its bundled 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-sources.sh

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?

--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to