[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NPM importer
Re: NPM importer
Wed, 21 Nov 2018 18:15:03 +0100
Le 2018-11-21 17:37, Giovanni Biscuolo a écrit :
address@hidden (Ludovic Courtès) writes:
Yes, this was the topic of a GSoC project by Jelle Licht (Cc’d). But
don’t hold your breath: as Chris Webber explained, the npm situation
very hard to address sanely:
(semi OT: today Debian ships a recent jquery 3.2.1)
I'm not an expert in js (nor guix) packaging so I'm not able to judge
is yarn a viable solution to the NPM packaging problems?
can we achieve reproducible builds ala guix with a yarn importer and
some amount of yarn packages downloading/automation and offline
How different is it to build an npm package and a yarn package? Could
you elaborate a bit on your idea?
We can already build packages with our wip node-build-system, as long as
we have build- and run-time dependencies available. The real hard parts
are: sometimes build-tools depend on what they build, there is just too
many dependencies and some packages don't declare a license properly.
For instance, grunt is a build tool for node packages; it has 179
dependencies at runtime (including recursive dependencies). All of them
need to be built before grunt can be run. What's the chance that none of
them require grunt? I haven't taken the time to look at these
dependencies, so maybe I'm pessimistic with no good reason.
Another instance is application-config-path that declares its license
only in the Makefile, in the form of "License: MIT". Do we consider this
Now if yarn has some build recipes and has taken the time to make this
whole mess more manageable, I'm all for a yarn importer. Otherwise, it's
just another source of package information, which is fine, but npm seems
to do the job already.
Xelera IT Infrastructures
Re: NPM importer, Ludovic Courtès, 2018/11/11