2022-11-19 18:27 zamfo...@twdb.moe:
Hello, Guix!
Hello :)
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.
Thanks for bringing this back up!
Although, I work with the node/npm ecosystem on a daily basis, unfortunately,
I don't really understand why it's so difficult to import npm-packages into
Guix.
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.
Is importing npm-packages into Guix difficult because npm-packages have so
many dependencies?
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.
Is importing npm-packages into Guix so difficult because we have a
chicken-and-egg problem, since many build-time dependencies (like TypeScript)
have so many dependencies themselves?
Also, is there a reason to choose esbuild over rust-swc (or vice versa)?
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.)
Could we also build TSC with Esbuild, and then use TSC to build packages that
depend on it, instead of mimicking TSC with Esbuild? Does that make sense?
With "mimicking TSC", do you mean that Esbuild does not transpile multiple
.ts-files at once? (By the way, Esbuild seems to make use of the tsconfig.json
file, according to <https://esbuild.github.io/api/#tsconfig>.)
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!)
That's so great!
Sorry for asking nooby questions. I just want to catch up and press ahead with
the discussion.