Mekeor Melire <mek...@posteo.de> writes: > 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? >
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.