Hello! Thanks for responding. The premise of the idea I’m proposing is that it wouldn’t be necessary to traverse into (most of) the ‘devDependencies’ if you build the packages ad‐hoc using esbuild. So, the idea is to sidestep the build process that the package has, and just invoke esbuild on the appropriate files of the package. My hope is that this is sufficient to bring most (or at least a lot of) useful packages from npm to Guix without the need of a binary importer.
I set up a package for sucrase as a proof of concept, since sucrase is a CLI tool that can be run and tried out easily (as opposed to jQuery, which is a library meant to be used in browsers). However, note that following my proposed approach, packaging jQuery becomes entirely trivial — it is a matter of simply running esbuild on jQuery’s input files. For the sake of example, I have included a Guix package I created for jQuery in the GitHub Gist I sent above. (And I can anecdotally verify that it works when tring it on a browser.) <https://gist.github.com/zamfofex/eac93bc0e00477a8b79f5ca4dc1a34ff#file-jquery-scm> I will admit that I cheated a bit, since I used the currently unreleased 4.0.0 version, as opposed to the latest released 3.x versions, since the realeased 3.x versions use the old and outdated AMD format (“asynchronous module definition”) for representing dependencies between files in a project. (See <https://github.com/evanw/esbuild/issues/1035>) However, most packages nowadays have already moved away from AMD (and jQuery is getting there), so this shouldn’t be an issue in practice.
