3 ms·

Browserify is awesome, and I look forward to reading this guide in detail, but I must say I'm disappointed about the "avoiding ../../../.." section. I've never

Browserify is awesome, and I look forward to reading this guide in detail, but I must say I'm disappointed about the "avoiding ../../../.." section. I've never seen a solution to this problem that wasn't a hack. The doc is correct that using NODE_PATH makes your app "tightly coupled to a runtime environment configuration", but what it fails to note is that the other two solutions offered are just as ugly. Checking code into a directory managed by npm is simply asinine, and putting symlinks in there is just as "coupled to the runtime environment configuration" as the NODE_PATH solution. What is really needed is a reasonable (and supported) method of programmatically managing the node search path. Why the node community is so stubborn about this point is a mystery to me and it makes me wary of node in general, because who wants to be locked into an environment where such an obvious pain point is ignored due to stubbornness?

cshenoy 12y ago
Do you have a better solution in mind? I'm actually wondering because I've thought of workarounds but they'd all be hacks like the ones in the handbook. I'd imagine other node developers are in the same boat (not due to stubbornness) otherwise we would've seen something by now. Basically, what would be your ideal solution?
- indirectlylit 12y ago
  There are good discussions of this issue at https://gist.github.com/branneman/8048520/ https://gist.github.com/branneman/8048520/ and http://stackoverflow.com/questions/10860244/ http://stackoverflow.com/questions/10860244/ My preference is to add structure with file names instead of directories: app.foo.bar.js instead of app/foo/bar.js
  - hamburglar 12y ago
    Unfortunately in that first link, isaacs is on record as saying we should just check our code into a node_modules directory. "Problem solved." This is exactly the kind of stubbornness I'm talking about.
    - garthk 12y ago
      All the pain and exhaustion is a sign you're fighting your way uphill instead of downhill. Node works brilliantly if you publish lots of tiny modules in public, @substack style. Unfortunately, some of us need to live uphill. I find the tiny module style works pretty well for me, but I need private code. I haven't yet found a private registry solution I like. NPM's lack of support for any "get this module from this registry" directive in package.json forces them to proxy the main registry. They're not good at it. I'm still declaring my dependencies by tarball URL, losing semantic version specs, e.g. "most recent compatible with 4.x". It strikes me as unlikely now to change in any way other than "here, use my paid-for private registry", because shareholders. That makes me unhappy, but not unhappy enough to ditch the public Node ecosystem and go back to what I was using before. It had its own uphill, and living there was harder.
      - hamburglar 12y ago
        One thing that amazes me is the arrogance with which people who like this scheme can make pronouncements about right and wrong ways to organize code. From the most popular answer on the stackoverflow link: "If you find yourself loading common files from the root of your project (perhaps because they are common utility functions), then that is a big clue that it's time to make a package." I'm sorry, but no, that is not a big clue that it's time to make a package. Every project I've ever worked on contained internal modules which were nicely organized and isolated, and were consumed by the rest of the project as black box "libraries" for good design's sake, but breaking them out into separately installable modules would have been sheer, unproductive bureaucracy. Oops, you made your code modular! Get ready to start managing packages! It's as if npm no longer wants to be merely a package manager, but also have a say in how your project internals are laid out as well. Perhaps it's a self-perpetuation strategy.
        garthk 12y ago
        I think you might be attributing stronger emotional intent than is present. They disagree about whether it's worth fundamentally changing npm's search method to avoid some ../.. paths in your argument to require. require aside, you can express yourself through your code however you like.
- hamburglar 12y ago
  The obvious thing is what most other environments do: there's a system default search path, you can override that using an environment var, and then once your runtime is up, you can further override it via an API at runtime. E.g. with ruby there is an array called $: which is the current search path in array-of-strings form, and manipulating that array affects the module loading behavior. This provides a lot of flexibility in how apps find their modules. Node provides basically none. Dictating that the only way to control dependency-loading is by manipulating the filesystem is really braindead.
- wetmore 12y ago
  I like the approach found here: https://github.com/DSKrepps/requireFrom https://github.com/DSKrepps/requireFrom It doesn't work with browserify but it wouldn't be too hard to write a transform that does it.
mambodog 12y ago
I think it is acceptable at the application level to use NODE_PATH, provided you have a normal node_modules directory at the root of your app for npm modules, and are strict about pulling out any generic modules to that location (and ideally, to npm), and that they never reference your private modules. Most substantial applications are going to have at least some small amount of internal coupling around their business logic and configuration, and as long as you limit knowledge of the custom NODE_PATH to that code you should be alright. eg. you could have # assuming git, find repo root APP_ROOT=$(git rev-parse --show-toplevel) # /app is for private, checked in modules # `npm root` will find your root node_modules dir NODE_PATH="$APP_ROOT/app:`npm root`" and then all of your app-coupled private modules can live in /app, and get checked into your git repo, while all the dependencies would be referenced in the package.json at the root of your app, and installed to node_modules (eg. npm root for the app package). I should emphasise that taking this approach requires quite a bit of developer responsibility to avoid coupling between modules when it's not required, and it's really overkill for small apps.

cshenoy 12y ago

Do you have a better solution in mind? I'm actually wondering because I've thought of workarounds but they'd all be hacks like the ones in the handbook. I'd imagine other node developers are in the same boat (not due to stubbornness) otherwise we would've seen something by now. Basically, what would be your ideal solution?

indirectlylit 12y ago
There are good discussions of this issue at https://gist.github.com/branneman/8048520/ https://gist.github.com/branneman/8048520/ and http://stackoverflow.com/questions/10860244/ http://stackoverflow.com/questions/10860244/ My preference is to add structure with file names instead of directories: app.foo.bar.js instead of app/foo/bar.js
- hamburglar 12y ago
  Unfortunately in that first link, isaacs is on record as saying we should just check our code into a node_modules directory. "Problem solved." This is exactly the kind of stubbornness I'm talking about.
  - garthk 12y ago
    All the pain and exhaustion is a sign you're fighting your way uphill instead of downhill. Node works brilliantly if you publish lots of tiny modules in public, @substack style. Unfortunately, some of us need to live uphill. I find the tiny module style works pretty well for me, but I need private code. I haven't yet found a private registry solution I like. NPM's lack of support for any "get this module from this registry" directive in package.json forces them to proxy the main registry. They're not good at it. I'm still declaring my dependencies by tarball URL, losing semantic version specs, e.g. "most recent compatible with 4.x". It strikes me as unlikely now to change in any way other than "here, use my paid-for private registry", because shareholders. That makes me unhappy, but not unhappy enough to ditch the public Node ecosystem and go back to what I was using before. It had its own uphill, and living there was harder.
    - hamburglar 12y ago
      One thing that amazes me is the arrogance with which people who like this scheme can make pronouncements about right and wrong ways to organize code. From the most popular answer on the stackoverflow link: "If you find yourself loading common files from the root of your project (perhaps because they are common utility functions), then that is a big clue that it's time to make a package." I'm sorry, but no, that is not a big clue that it's time to make a package. Every project I've ever worked on contained internal modules which were nicely organized and isolated, and were consumed by the rest of the project as black box "libraries" for good design's sake, but breaking them out into separately installable modules would have been sheer, unproductive bureaucracy. Oops, you made your code modular! Get ready to start managing packages! It's as if npm no longer wants to be merely a package manager, but also have a say in how your project internals are laid out as well. Perhaps it's a self-perpetuation strategy.
      - garthk 12y ago
        I think you might be attributing stronger emotional intent than is present. They disagree about whether it's worth fundamentally changing npm's search method to avoid some ../.. paths in your argument to require. require aside, you can express yourself through your code however you like.
hamburglar 12y ago
The obvious thing is what most other environments do: there's a system default search path, you can override that using an environment var, and then once your runtime is up, you can further override it via an API at runtime. E.g. with ruby there is an array called $: which is the current search path in array-of-strings form, and manipulating that array affects the module loading behavior. This provides a lot of flexibility in how apps find their modules. Node provides basically none. Dictating that the only way to control dependency-loading is by manipulating the filesystem is really braindead.
wetmore 12y ago
I like the approach found here: https://github.com/DSKrepps/requireFrom https://github.com/DSKrepps/requireFrom It doesn't work with browserify but it wouldn't be too hard to write a transform that does it.

mambodog 12y ago

I think it is acceptable at the application level to use NODE_PATH, provided you have a normal node_modules directory at the root of your app for npm modules, and are strict about pulling out any generic modules to that location (and ideally, to npm), and that they never reference your private modules. Most substantial applications are going to have at least some small amount of internal coupling around their business logic and configuration, and as long as you limit knowledge of the custom NODE_PATH to that code you should be alright. eg. you could have # assuming git, find repo root APP_ROOT=$(git rev-parse --show-toplevel) # /app is for private, checked in modules # `npm root` will find your root node_modules dir NODE_PATH="$APP_ROOT/app:`npm root`" and then all of your app-coupled private modules can live in /app, and get checked into your git repo, while all the dependencies would be referenced in the package.json at the root of your app, and installed to node_modules (eg. npm root for the app package). I should emphasise that taking this approach requires quite a bit of developer responsibility to avoid coupling between modules when it's not required, and it's really overkill for small apps.