Re: bringing npm packages to Guix

[Joshua Branson <jbranso@dismail.de>]

Mekeor Melire <mekeor@posteo.de> writes:

> 2022-11-19 18:27 zamfofex@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?
>

Yes.  The recursive javascript importer that was written, generates
package definitions that are larger than the source code for the
packages.  It's quite a hairy problem.

>> 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.