3 ms·

You might be trolling, but custom $NODE_PATH configurations are a slippery slope and can reintroduce dependency hell f you're not careful. You're voluntarily di

by secoif 14y ago

You might be trolling, but custom $NODE_PATH configurations are a slippery slope and can reintroduce dependency hell f you're not careful. You're voluntarily disabling one of npm's finest features. This sentiment is even in the manual: "[$NODE PATH exists] mostly for historic reasons. You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably." http://nodejs.org/api/modules.html#modules_loading_from_the_global_folders http://nodejs.org/api/modules.html#modules_loading_from_the_...

myhf 14y ago
I actually use $NODE_PATH, mostly for historical reasons. It would certainly get unwieldy if you added more than one directory to it. It's nice to have a place for small shared library files that don't justify their own package.json, but as things get more mature they end up in node_modules.
- secoif 14y ago
  May be a valid use case so long as you know what you're doing, and if this works for you, that's great. Though, considering the fact it's generally a bad idea, advising people to break the rules should probably be qualified with a serious disclaimer when presented in the comments of a post appealing to beginners... > ...small shared library files that don't justify their own package.json... Generating a package.json + dependencies is a 30 second job with npm init + npm install --save + npm link. I follow a similar pattern to you when developing inside a single module, where I start growing module saplings in a ./lib folder to spike on ideas without the overhead of totally decoupling from the parent, but as soon as you need to share that code around and put it into your $NODE_PATH, you've got to decouple it anyway, so really you're effectively 30 seconds worth of work away from creating a real module anyway, and thus you could do away with your custom $NODE_PATH.

by secoif 14y ago

myhf 14y ago

I actually use $NODE_PATH, mostly for historical reasons. It would certainly get unwieldy if you added more than one directory to it. It's nice to have a place for small shared library files that don't justify their own package.json, but as things get more mature they end up in node_modules.

secoif 14y ago
May be a valid use case so long as you know what you're doing, and if this works for you, that's great. Though, considering the fact it's generally a bad idea, advising people to break the rules should probably be qualified with a serious disclaimer when presented in the comments of a post appealing to beginners... > ...small shared library files that don't justify their own package.json... Generating a package.json + dependencies is a 30 second job with npm init + npm install --save + npm link. I follow a similar pattern to you when developing inside a single module, where I start growing module saplings in a ./lib folder to spike on ideas without the overhead of totally decoupling from the parent, but as soon as you need to share that code around and put it into your $NODE_PATH, you've got to decouple it anyway, so really you're effectively 30 seconds worth of work away from creating a real module anyway, and thus you could do away with your custom $NODE_PATH.