undefined | Better HN

0 pointsedude0310y ago0 comments

npm is an example of a bad solution to dep management. So I want you to run my 6kb node.js script you need to:

1) Build obtain node for your platform (and now you've hit the exact problem I'm talking about) 2) install npm (which I can't really define as a dep, you're just expected to have it) 3) install all the deps I've defined and hope they all work on the version / configuration of node you have (execjs only works on node 0.10 but you have v4? Too bad! You didn't apply the increased memory patch before building node? Too bad!)

The ideal here to reiterate is given nothing but your installed OS, I should be able to give you a file that will go from nothing to a running app, and from the running app to a clean system if you decide to remove it, without you having to have any prerequisites (no node, no chef, no docker, etc)

0 comments

3 comments · 2 top-level

sebular10y ago· 1 in thread

I don't think you can really complain about having to have node.js installed in order to run a node.js script.

If you want self-contained binaries, learn Go. If you want lightweight scripts that run effortlessly on all unix systems, learn bash scripting. It sort of sounds to me like you're complaining about not being able to shoehorn your chosen language into all possible scenarios.

edude03OP10y ago

I think that's a very reasonable thing to complain about in the context of dependency management. The runtime (node.js) and it's compile time + run time options are actually a dependancy of your application.

As an end user, I shouldn't be expected to know how to configure x dependancy for my system to run y app and as a software developer I shouldn't have to build / package apps to match the client's system configuration.

The sticking point is (back to my point) that the vast majority of distributions don't give the app a way to manage the deps and get specific deps in required, the best you can do is list x as a dep in your package and hope that it won't break your app or the system in some way.

falcolas10y ago

Agreed. Have two dependencies which have the same underlying dependency? Install and compile that dependency twice (with two different versions, by the way)[1]. Want to use grunt? Need to set that up as a dependency for your project, but only for development. A problem while installing? Have fun with the debug output detailing the fetching a building of every dependency, and every dependency's dependency, and every dependency's dependency's dependency... etc.

[1] I can't believe how many distinct copies and versions of the 'shell' module are downloaded and compiled when pulling in a seemingly simple set of modules.

j / k navigate · click thread line to collapse