[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NPM importer

From: swedebugia
Subject: Re: NPM importer
Date: Wed, 21 Nov 2018 16:36:26 +0100

On 2018-11-20 23:35, Julien Lepiller wrote:
Le Tue, 20 Nov 2018 22:12:18 +0100,
swedebugia <address@hidden> a écrit :


On 2018-11-20 20:58, swedebugia wrote:
On 2018-11-20 08:50, Julien Lepiller wrote:


See this script that builds a graph of dependencies, ignoring
devDependencies (so none of the packages listed by this script is
going to be tested):

What is devDependencies? Required to build the npm package?

the package.json file declares two kinds (I think I've seen a third
kind, but I'm not sure, nor am I a js developper) of dependencies:
dependencies and devDependencies that map to our inputs and
native-inputs. devDependencies are tools used during the build or
development, but they are not needed at runtime. Sometimes, they are
required at build time (for instance the coffeescript compiler is a
devDependencies of some packages, but we need it to build the package),
usually they are required at test time (for instance mocha, tap, or
tape are test frameworks), otherwise, they can be documentation tools,
and sometimes really not useful for us (we probably don't want to run
linters or release-related tools).

Ok, that sounds resonable.
Maybe we can blacklist all these linters and release tools during import and import everything else as dependencies?


The way I wrote it, you were supposed to change the "mocha" with the
package you're interested in, and run the script with guile like so:

guile npm-explorer.scm >

and then:

fdp -Tpng > mocha.png

(fdp is part of graphviz, but produces nicer graphs than dot in my



npm.scm will be a VERY VERY long file. Maybe we should rethink about
how to best store all these variables...

Very long files are frowned upon, because they have very long
compilation times and require a lot of memory. We'll have to find a way
to split the file before it grows too much. Maybe we will do something
similar than python packages? We have python.scm, python-web.scm...

yeah good idea. but with half a miljon packages and maybe max a 1000 definitons in each we will still have ~500 npm files. By then I suggest we put them in a separate dir like gnu/packages/npm/web.scm etc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]