unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* bringing npm packages to Guix
@ 2022-11-19 21:27 zamfofex
  2022-11-21 11:13 ` Ludovic Courtès
  2022-12-20  9:00 ` Mekeor Melire
  0 siblings, 2 replies; 5+ messages in thread
From: zamfofex @ 2022-11-19 21:27 UTC (permalink / raw)
  To: guix-devel@gnu.org

Hello, Guix!

A few months ago, I picked up the work towards importing npm packages to Guix by Jelle et al. in the hopes of continuing it, and I felt disheartened when I concluded that it does indeed seem like a very large part of npm is necessary to build even a simple package like jQuery.

But, recently, I decided to spend some more time thinking about it, and I realized that not all of the ‘devDependencies’ of a given package are actually necessary to build it. A lot of packages have ‘devDependencies’ for things such as tests and watching the filesystem for changes for ease of development.

If you think about it, what the vast majority of npm packages need to build successfully comes down to (optionally) compile TypeScript, then (optionally) perform some kind of bundling or transpilation. And that doesn’t really require TypeScript or a build tool from npm, since esbuild (which is already packaged) can do both of those things by itself.

Now, taking away the ‘devDependencies’ when recursing the dependency tree makes the whole endeavor of importing an npm package seem *much less* difficult and scary! The biggest unfortunate issue is that for packages with a build step (TypeScript and/or bundling+transpilation), it is necessary to use esbuild ad‐hoc (i.e. in a case-by-case basis), because each package has its own build peculiarities, and esbuild doesn’t acknowledge them. (One solution could be to create an esbuild wrapper that mimics ‘tsc’ and other tools.)

With that approach in mind, I was able to package sucrase as a proof of concept! Note that sucrase doesn’t have a lot of transitive dependencies, so it was easy to just modify the phases of each package in an ad‐hoc way. However, also note that sucrase depends on itself, so I decided to bootstrap it with esbuild, then use the bootstrapped version to build sucrase again. (The bootstrapped sucrase seems to also work as expected!)

The import script I wrote, alongside the sucrase package itself can be found here:
- <https://gist.github.com/zamfofex/eac93bc0e00477a8b79f5ca4dc1a34ff>

Any kinds of thoughts or feedback on this would be appreciated!

A few notes of potential future work:

- Keep tests on packages, after packaging the necessary test libraries.
- Maybe: Write a wrapper for esbuild for mimicking ‘tsc’ and other tools. (As mentioned above.)
- Figure out a way to detect vendored dependencies and other forms of bundles in repositories.
- Polish the import script, and make it fit Guix’ style and formatting practices.
- Use the ‘version’ variable in the source field of package definitions when importing. (An extension of the item above.)


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-12-20 14:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-19 21:27 bringing npm packages to Guix zamfofex
2022-11-21 11:13 ` Ludovic Courtès
2022-11-21 22:52   ` zamfofex
2022-12-20  9:00 ` Mekeor Melire
2022-12-20 14:01   ` Joshua Branson

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).