4 ms·

"Instead of including modules by complicated pathing like require('../../../shared/utils'), it’s much simpler to require('utils'). Utils can be symlinked from a

"Instead of including modules by complicated pathing like require('../../../shared/utils'), it’s much simpler to require('utils'). Utils can be symlinked from another folder in the source tree so that you can continue to actively develop it and the changes will be reflected in the dependent modules." This sounds like a maintenance nightmare when you start juggling lots of code.

myhf 14y ago
Yes, it would be much simpler to add "shared" to $NODE_PATH or to place shared modules in "node_modules" by having NPM check them out over git.
- 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.
beck5 14y ago
Also important to not fall down the hole in a couple of years where these shared libraries are being used all over the place and changing them becomes hard. Good to always question if they should be a module or perhaps their own api.
- nailer 14y ago
  Agreed re: shared libraries being used all over the place, but I don't think that requires changing a module to an API. git submodules are designed to solve this problem and do so very well, allowing each project that uses a shared module to include whatever version it pleases, yet allowing the project using the shared module to update/rollback to a newer/older version.
MatthewPhillips 14y ago
Also won't be compatible with Windows.
calvinfo 14y ago
This is definitely a fair point. So far, we've found it to work well by keeping our packages fairly well organized. A simpler solution might be to put your custom modules in node_modules (without symlinking) and then commit those to your source tree. The main point that I wanted to get across was that it's worth structuring your packages in such a way that makes it easy for developers to write new modules without using a lot of relative paths in the file system. Node does this work already, so I like to take advantage of it.
2mur 14y ago
Not really. You just develop independent, reusable modules, drop a package.json in the module and npm link the module to your app. It gets symlinked to your app's node_modules.
jergason 14y ago
We did that in an early node app, and it indeed turned in to a nightmare.

myhf 14y ago

Yes, it would be much simpler to add "shared" to $NODE_PATH or to place shared modules in "node_modules" by having NPM check them out over git.

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.

beck5 14y ago

Also important to not fall down the hole in a couple of years where these shared libraries are being used all over the place and changing them becomes hard. Good to always question if they should be a module or perhaps their own api.

nailer 14y ago
Agreed re: shared libraries being used all over the place, but I don't think that requires changing a module to an API. git submodules are designed to solve this problem and do so very well, allowing each project that uses a shared module to include whatever version it pleases, yet allowing the project using the shared module to update/rollback to a newer/older version.

MatthewPhillips 14y ago

Also won't be compatible with Windows.

calvinfo 14y ago

This is definitely a fair point. So far, we've found it to work well by keeping our packages fairly well organized. A simpler solution might be to put your custom modules in node_modules (without symlinking) and then commit those to your source tree. The main point that I wanted to get across was that it's worth structuring your packages in such a way that makes it easy for developers to write new modules without using a lot of relative paths in the file system. Node does this work already, so I like to take advantage of it.

2mur 14y ago

Not really. You just develop independent, reusable modules, drop a package.json in the module and npm link the module to your app. It gets symlinked to your app's node_modules.

jergason 14y ago

We did that in an early node app, and it indeed turned in to a nightmare.