How I Work Around The require(“../../../../../../../”) Problem In NodeJS

http://lostechies.com/derickbailey/2014/02/20/how-i-work-around-the-require-problem-in-nodejs/

by docluv • 12 years ago

43 41 12 years ago

lostechies.com

unwind• 12 years ago

The article seems to be missing crucial examples, making it very hard to read and follow. :/

tlarkworthy• 12 years ago

can't you install a private npm module by npm link? That won't touch the npm servers [1].

Then your other project in the same file system can just require like a first class public npm module.

[1] https://www.npmjs.org/doc/cli/npm-link.html

camus2• 12 years ago

The OP did not read npm doc obviously. npm link is the killer feature of npm.

royjacobs• 12 years ago

How do you go about setting these links when you freshly checked out a project through source control? There is no "npm link all", is there?

clux• 12 years ago

https://github.com/clux/symlink

dreamdu5t2• 12 years ago

npm scripts on install or prepublish

Jare2• 12 years ago

I don't think npm link is meant to be used in production like that.

2mur3• 12 years ago

You probably shouldn't be using npm for production builds. npm is good for libraries, but applications should probably be tarballed.

heydenberk• 12 years ago

Setting an environment variable to include a directory in which you have libraries that you need to use across your application is not a workaround. It's using a feature.

mcgwiz• 12 years ago

So? Asking earnestly, what exactly is your point? That the title offends you because it uses the phrase "work around"?

Adding a relative path to a *PATH variable is clever, elegant, useful, and uncommon. It resolves a problem not directly (by changing how 'require' works internally), but indirectly, aka "working around" it.

joel_perl_prog• 12 years ago

I've done this in the past on *nix systems, for Perl. I modified PERL5LIB from my .bashrc file, so that my project lib was looked for by default. This, rather than having to put 'use lib '../../../yikes/ugly' ahead of any inclusion of project modules.

Another approach, which I favor now, is to place modules directly into the default locations, such as /usr/lib/share/perl5 and etc.--usually there are a number of paths Perl looks at by default. It's then just a matter of saying 'use MyModule;' in code.

Is node.js similar, in having one or more include paths set by default, and could files be put there, to where you never have to refer to something by relative location again?

jbeja• 12 years ago

How this would work with browserify?

Touche• 12 years ago

Article appears to be down.

I've never worked on a Node project with directories that nested more than 3 or 4 levels deep, so I don't see this as a "problem" (but maybe the article makes a case that it is).

alexandere• 12 years ago

http://webcache.googleusercontent.com/search?q=cache:http://...

hippich• 12 years ago

I am not sure all your private code on git should be publicly accessible. Wouldn't it be possible to point dependency to private in-house GIT repository?

agilebyte• 12 years ago

That is the option (g) here:

https://www.npmjs.org/doc/install.html

You can also use your own npm registy using `--registry`:

https://www.npmjs.org/doc/misc/npm-registry.html

shtylman• 12 years ago

The fix for this is to use a module. Simple. Not a problem.

jt21902• 12 years ago

For me, a relative path in a require statement signifies that the required code is a part of the application itself.

Consider:

    require('foo');

Versus:

    require('./foo');

If I find that a module is becoming popular, I may turn it into an npm module by moving it to it's own folder and adding a package.json, then using npm's bundledDependencies property to inform npm that it lives locally.

(edit: Note that I've shifted my perspective on the module when this happens. The shift is from "This code is in a separate module to keep my application organized" to "This code is in a separate module because it has some logical independence from the application.")

If the module needed even more independence, I'd move it to it's own git repo and create an internal mirror of the npm repo so that it can be discovered internally, and unbundle it from my app. (I could see this happening especially with larger teams, or teams that embrace the "module all the things" philosophy.)

And of course, there's always the possibility of moving the module out to the public npm repos and hosting it there.

I've never had require with relative paths of more than two or three "double dots". (Note to self: Look up what those things are called formally.)

jaredsohn• 12 years ago

The double dots refer to the parent directory; I'm not sure that there is other associated terminology or if there is an easier way to express what you wrote.

2mur3• 12 years ago

If find it's easier to distinguish modules from files by requiring modules like:

  require('foo');

and application files like:

  require('./foo.js'); //.js extension

qubyte• 12 years ago

Imagine if you're requiring that local module throughout your codebase. Now suppose that the module has become large enough to be come a directory. All those requires with the .js extension will break! If you leave it off, then no problem. Always avoid adding the .js.

awinder• 12 years ago

I had this similar problem, but I solved it in a different way by creating a module outside of the node_modules folder, and putting a symlink in the node_modules folder. Read here to see how I broke this down http://winder.ws/blog/2013/10/15/structuring-local-node-modu...

jt21902• 12 years ago

Google Cache (text only): http://webcache.googleusercontent.com/search?q=cache:http://...

kybernetikos• 12 years ago

While I don't personally do this - I try to follow node idiom of having each package be a relatively thin layer of functionality and having packages depend on each other, I believe that you don't need to use relative paths if you don't want to.

For example, if your package is called my-node-module and you have something in my-node-module/lib/app/dir/thingy/wotsit/jimminy.js, it can reference something in my-node-module/lib/server/alf.js by simply going

    require("my-node-module/lib/server/alf.js");

There's no need for the relative path at all. It's possible that this only works if your package is in an node_modules directory (which it will be if it's installed as a dependency), but I always symlink my development directory to node_modules anyway.

jdc0589• 12 years ago

There are lots of workarounds. My preferred workaround isn't especially good, but it keeps me sane since I also hate having giant relative paths. https://gist.github.com/jdc0589/9115898

Usage is as follows:

    var pRequire("./projectRequire")(rootPathOfYourProject);
    var MyModule = pRequire("~/lib/foo/bar/myModule");

It doesn't really buy you anything over `require("nameOfYourPackage/path/to/module")`, but I like the consistent "~" prefix across projects using the same scheme.

Moving things to their own NPM package is a great solution when its something re-usable that logically makes sense to exist on it's own, but that isn't the case most of the time.

moron4hire• 12 years ago

This is half of why I much prefer .NET's namespacing. The other half is not having to declare every single thing a file full of code exports for use.

secoif• 12 years ago

Anyone with this problem is most likely working on a horrible monolith. You have far too much nesting and you're simply hiding the symptoms of a greater problem. Flat > nested. Simple > complex. Law of demeter also applies to reaching and in/out of folders. Break your app into more smaller modules rather than sweeping your mess under the rug.

ianstormtaylor• 12 years ago

+100 — NODE_PATH actually ends up being an anti-pattern because all of those internal modules are still not versionable. Instead, use a private NPM registry and just publish everything separately.

eldude• 12 years ago

Put one of the following in your package.json "postinstall" hook:

    npm link lib
    link -s lib node_modules/lib

Then:

    require('lib/models/user')

No matter where you are.

2mur3• 12 years ago

That is a code smell. node and require works really great with small modules. npm link in development, tarball up and scp to your box for deployment.

hellopat• 12 years ago

I made a module to solve this issue a while back.

https://github.com/hellopat/prequire

weavie• 12 years ago

I've been using the AngularJS dependency injection module for all my application code, [1] which means I am now only requiring libraries. I find it makes for much cleaner code and easier to test as well.

[1] https://github.com/FungusHumungus/pongular

arxpoetica• 12 years ago

A simple convention, as long as you know the process root:

var rootDir = process.cwd(); var config = require(rootDir + '/server/config');

And so forth.

nilgradisnik• 12 years ago

If you use requirejs for node, defining paths in requirejs.config solves this problem too.

dreamdu5t2• 12 years ago

Your project is horribly architected if you need to do relative requires this deep.

Applications can be decoupled into interoperable components. Separate modules for configuration, controllers, routing, etc.

Separate concerns into modules.

ahdinosaur• 12 years ago

I work around this problem in a couple projects by putting my code in modular directories in ./src/node_modules. no npm magic, no having to make symlinks or change path, just plain node. it also makes it very easy to publish your modules when you are ready, just take the module directory out, give it a package.json, npm publish the module, npm install --save the module back in the project.

wookimiii• 12 years ago

Isn't it possible to use private git repos to install packages? Why not just install packages from git instead of publishing to npm.

rodw• 12 years ago

Am I the only one that doesn't find this a problem?

My usual idiom is to do two things:

1. Part of my boilerplate at the top of every JS file is something like this:

    var path     = require('path');
    var HOMEDIR  = path.join(__dirname,'..','..');

where `__dirname` is the built-in variable that names the directory that contains the current file, and `'..','..'` is the requisite number of steps up the directory tree to reach the root of the project.

From there is it is simply:

    var foo = require(path.join(HOMEDIR,'lib','foo'));
    var bar = require(path.join(HOMEDIR,'lib','foo','bar'));

to load an arbitrary file within the project.

2. Long before I got to 8 levels deep in the directory tree I'd create a separate npm module to bundle the code together in a less spaghetti fashion.

For what it's worth, I typically use a branch on a private GitHub repository for my "private" modules. I.e., the master branch has the source code, and another (say, `npm-v1.2.3`) has the npm package of it.

andypants• 12 years ago

You don't have to make your code public if you want to use npm. You can use your own private npm repo. You can use npm to install packages from private git repos directly. You can use `npm link`. I'm sure there are a dozen more ways.

etler• 12 years ago

I think the best solution for this would be having a private npm server. With npm's recent incorporation and funding, I have a feeling that is going to be coming soon. It's helpful even for small companies, but once you have multiple internal projects all with inter-dependencies that can't be put out publically, it's pretty much a must.

How I Work Around The require(“../../../../../../../”) Problem In NodeJS

Related Stories