While updating some packages in `(gnu packages cran)` (to remove input
labels) I found a mention of jquery.min.js. This surprised me because
there is no jquery package in guix, at least as far as I can see.
Looking throughout the repo, there seem to be many cases (at least 10
different versions), packaged ad-hoc alongside other code. It seems
obvious to me that it would be better to at least put these ad-hoc
packages in a dedicated place, so we can upgrade them in a more uniform way.
I found Christine's article from 2015[1] which explains a bit about how
hard it would be to get an "ideal" jquery package. I also found an email
thread about the same time, but couldn't see any discussion since then.
I wonder if anything has changed, besides npm becoming incomprehensibly
larger, and what a good path forward would be.
I can see that node is packaged, that there is an npm-binary importer,
and that there is a javascript-team in guix.
I was able to download the jquery source and build version 4.0.0 using
the version of node currently packaged in guix, which is encouraging.
As far as I can tell the binary importer just fetches a tarball from the
NPM registry, which is not necessarily reproducible. From a
reproducibility standpoint, it seems like it would be a strict
improvement to have a build system which tries to run `npm install` /
`npm run build` within the store. I guess this would require a mechanism
for ensuring npm install always produces the same node_modules
directory. Perhaps this is too much to hope for -- I just tried running
npm install twice and `guix hash -r` reported different hashes. However
`npm run build` did produce an identical `jquery.js` file.
There are obvious downsides to running npm install.
1. It produces huge node_modules directories.
2. Dependencies are repeated, and deduplication seems complicated.
Running `npm dedupe`[2] did not result in a fully deduplicated tree (it
only fixed about 4 examples).
I suppose the dream would be an importer that can read the source of an
NPM package and deduce what build actions and dependencies are suitable,
presumably by reading `package.json` and `package-lock.json`. I don't
know if anyone has made any effort in this direction.
In the spirit of giving actionable steps, here is what I would propose
doing, in increasing order of difficulty:
1. Identify all existing jquery blobs (plus possibly other JS libs) and
put them in a module as hidden packages (possibly js-blobs to emphasise
their problematic nature).
2. Write an npm build system which does a simple `npm install` / `npm
run build` and puts the `dist` or `build` directory in the store. This
would provide a mechanism to eliminate the existing blobs.
3. Write an importer that tries to recursively build a manifest out of
package.json and package-lock.json.
I'm interested to see what others think, particularly on the javascript
team.
Best wishes,
Dan
[1]: https://dustycloud.org/blog/javascript-packaging-dystopia/
[2]: https://docs.npmjs.com/cli/v9/commands/npm-dedupe
