tech-pkg archive

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

Re: What's the story for NPM packages?



14. 11. 2014 v 9:48, Benny Siegert <bsiegert%NetBSD.org@localhost>:
> 
> I am dabbling with some web stuff and so I tried the node.js pkgsrc
> package. While it works perfectly fine (thanks for that!), what about
> npm?
> 
> When you try to install, say, bower "globally", it is trying to write
> directly under /usr/pkg, which is probably not a good idea. Then
> again, installing bower pulls in literally hundreds of npm
> dependencies, so I don't think that adding pkgsrc packages for each
> individual one is a good use of anyone's time.
> 
> So what should we do? Maybe add logic to npm to create "ephemeral"
> packages and at least register the metadata? Or do hundreds of trivial
> packages, cpan-style?

Creating pkgsrc packages doesn’t really apply to npm at all.

platypus:/usr/pkg/lib/node_modules $ find * -type d -name bunyan
manta/node_modules/bunyan
manta-nfs/node_modules/bunyan
manta-nfs/node_modules/manta/node_modules/bunyan
manta-nfs/node_modules/manta/node_modules/restify/node_modules/bunyan
manta-nfs/node_modules/mantafs/node_modules/bunyan
smartdc/node_modules/bunyan

You could argue if that’s the best way to solve the traditional "abc-1.2.3 requires def-4.5.6 and none other” problem, but it obviously works for the Node.js world.

As far as writing to $PREFIX goes, I’d surprised if global modules were really wide spread. The best practice says to use bundled dependencies (same as in the Rails world) and it’s what I’d expect of any production quality node.js app. On my work system were I need some CLI tools (e.g. json, the Joyent modules above), I don’t really care.

Open to suggestions… but I don’t really see a clean way out of this.

-F


Home | Main Index | Thread Index | Old Index