4 ms·

The obvious question is how much work it'll be to turn each NPM into a system package for production use. It took us months to straighten out a nest of servers

The obvious question is how much work it'll be to turn each NPM into a system package for production use. It took us months to straighten out a nest of servers which had assorted unique versions of code smuggled onto them with ad hoc single-language tools completely lacking RPM integration, and we're not about to go there again. The sample package.json doesn't show any way to list native (non-node) dependencies, which is not a good sign.

catch23 15y ago
I think the idea is to NOT do that. If you're doing it in production, you probably run your node in user level anyway, so you should have node installed via nvm or similar tool. Why would you want package.json to list native dependencies, shouldn't that be the responsibility of the npm package author? Usually npm packages that compile to native code will run 'make' on 'npm install'. Another reason that you would NOT want this is because npm packages could potentially use older conflicting versions of the same library. NPM can manage this internally -- you wouldn't want rpm to install 2 different versions of the same package globally. In the contrived example below, cluster & express are using 2 different versions of the 'log' npm package, but the main system using cluster & express have no clue that there are 2 different versions installed. ├─┬ cluster@0.6.9 │ └── log@1.2.0 ├── ejs@0.4.3 └─┬ express@2.0.0 ├── log@1.0.0 ├── connect@1.1.0 └── qs@0.3.0
mtodd 15y ago
Sounds like you should be using Chef or Puppet to manage these kinds of dependencies.
- prodigal_erik 15y ago
  Last I looked, both Chef and Puppet were meta-tools that launch all the other third-party tools I don't want involved. Are either of them solid enough now to actually replace the system package manager? Can they answer questions like "why does /etc/foo exist, which package created that?"

catch23 15y ago

I think the idea is to NOT do that. If you're doing it in production, you probably run your node in user level anyway, so you should have node installed via nvm or similar tool. Why would you want package.json to list native dependencies, shouldn't that be the responsibility of the npm package author? Usually npm packages that compile to native code will run 'make' on 'npm install'. Another reason that you would NOT want this is because npm packages could potentially use older conflicting versions of the same library. NPM can manage this internally -- you wouldn't want rpm to install 2 different versions of the same package globally. In the contrived example below, cluster & express are using 2 different versions of the 'log' npm package, but the main system using cluster & express have no clue that there are 2 different versions installed. ├─┬ cluster@0.6.9 │ └── log@1.2.0 ├── ejs@0.4.3 └─┬ express@2.0.0 ├── log@1.0.0 ├── connect@1.1.0 └── qs@0.3.0

mtodd 15y ago

Sounds like you should be using Chef or Puppet to manage these kinds of dependencies.

prodigal_erik 15y ago
Last I looked, both Chef and Puppet were meta-tools that launch all the other third-party tools I don't want involved. Are either of them solid enough now to actually replace the system package manager? Can they answer questions like "why does /etc/foo exist, which package created that?"