How can I make Node.js 'require' absolute? (instead of relative)

Question

I would like to 'require' my files always by the root of my project and not relative to the current module.

For example, if you look at Express.js' app.js line 6, you will see

express = require('../../')

That's really bad, IMO. Imagine I would like to put all my examples closer to the root only by one level. That would be impossible, because I would have to update more than 30 examples and many times within each example. To this:

express = require('../')

My solution would be to have a special case for root based: if a string starts with an $ then it's relative to the root folder of the project.

What can I do?

Update 2

Now I'm using RequireJS which allows you to write in one way and works both on client and on server. RequireJS also allows you to create custom paths.

Update 3

Now I moved to Webpack and Gulp.js and I use enhanced-require to handle modules on the server side. See here for the rationale: http://hackhat.com/p/110/module-loader-webpack-vs-requirejs-vs-browserify/

Swearingen

If you ever decide to use an explicit root path constant/variable, this answer works for that. The solution uses a tiny github module to determine the root path. – Uttica

gist.github.com/branneman/8048520 – Quinonoid

The link at the end is (effectively) broken: It redirects to a generic page. – Katekatee

Answer 1

Here is the actual way I'm doing for more than 6 months. I use a folder named node_modules as my root folder in the project, in this way it will always look for that folder from everywhere I call an absolute require:

• node_modules
  • myProject
    • index.js I can require("myProject/someFolder/hey.js") instead of require("./someFolder/hey.js")
    • someFolder which contains hey.js

This is more useful when you are nested into folders and it's a lot less work to change a file location if is set in absolute way. I only use 2 the relative require in my whole app.

Swearingen

I use similar approach, except that I add local (project's) node_modules in /src, and leave /node_modules for vendors to keep things separate. So I have /src/node_modules for local code and /node_modules for vendors. – Pepita

IMHO the node_modules folder is just for node_modules. It is not a good practice to put your whole project inside that folder. – Discreet

@Discreet what would you suggest as an alternative to get the same effect as above? – Geny

@cspiegl You can use the NODE_PATH environment variable – Ence

Answer 2

Use:

var myModule = require.main.require('./path/to/module');

It requires the file as if it were required from the main JavaScript file, so it works pretty well as long as your main JavaScript file is at the root of your project... and that's something I appreciate.

Ravage

Not a bad idea (: You can then define some other methods to somehow remap the app in your require.main module. I think you could then do require.main.req('client/someMod'). Nice idea, but this would be more verbose than my current requirejs. Also I don't think is worth because I also dislike browserify because changes are not instant and misses changes (because my code should run both in browser and node.js). – Swearingen

If you find it too verbose, just use .bind(): var rootReq = require.bind( require.main ) ; rootReq( './path/to/module' ) ; – Ravage

yes, this can be useful for someone that still wants to use browserify for client side. For me there is no need anymore, but thanks anyway for your answer (: – Swearingen

This looks good, but note that it only works if the "main" code is always from the same path, which was not the case for me because the test runner executed from within it's node_modules home vs. main project running from root folder. – Sacral

IF MAIN IS AT THE ROOT OF YOUR PROJECT :) – Sensillum

This solution will not work if code covered with unit tests like Mocha test – Myrmidon

for a solution that also works with mocha see my answer below. – Nolly

Answer 3

There's a really interesting section in the Browserify Handbook:

avoiding ../../../../../../..

Not everything in an application properly belongs on the public npm and the overhead of setting up a private npm or git repo is still rather large in many cases. Here are some approaches for avoiding the ../../../../../../../ relative paths problem.

node_modules

People sometimes object to putting application-specific modules into node_modules because it is not obvious how to check in your internal modules without also checking in third-party modules from npm.

The answer is quite simple! If you have a .gitignore file that ignores node_modules:

node_modules

You can just add an exception with ! for each of your internal application modules:

node_modules/*
!node_modules/foo
!node_modules/bar

Please note that you can't unignore a subdirectory, if the parent is already ignored. So instead of ignoring node_modules, you have to ignore every directory inside node_modules with the node_modules/* trick, and then you can add your exceptions.

Now anywhere in your application you will be able to require('foo') or require('bar') without having a very large and fragile relative path.

If you have a lot of modules and want to keep them more separate from the third-party modules installed by npm, you can just put them all under a directory in node_modules such as node_modules/app:

node_modules/app/foo
node_modules/app/bar

Now you will be able to require('app/foo') or require('app/bar') from anywhere in your application.

In your .gitignore, just add an exception for node_modules/app:

node_modules/*
!node_modules/app

If your application had transforms configured in package.json, you'll need to create a separate package.json with its own transform field in your node_modules/foo or node_modules/app/foo component directory because transforms don't apply across module boundaries. This will make your modules more robust against configuration changes in your application and it will be easier to independently reuse the packages outside of your application.

symlink

Another handy trick if you are working on an application where you can make symlinks and don't need to support windows is to symlink a lib/ or app/ folder into node_modules. From the project root, do:

ln -s ../lib node_modules/app

and now from anywhere in your project you'll be able to require files in lib/ by doing require('app/foo.js') to get lib/foo.js.

custom paths

You might see some places talk about using the $NODE_PATH environment variable or opts.paths to add directories for node and browserify to look in to find modules.

Unlike most other platforms, using a shell-style array of path directories with $NODE_PATH is not as favorable in node compared to making effective use of the node_modules directory.

This is because your application is more tightly coupled to a runtime environment configuration so there are more moving parts and your application will only work when your environment is setup correctly.

node and browserify both support but discourage the use of $NODE_PATH.

Dissimilate

Thanks (: that is amazing. Fortunately I don't need it anymore. As I'm sharing code between client and server all my app use require.js which enables you to create paths a lot more easily and doesn't have the node_modules hardcoded variable which was a pain. I don't even like the name, it should be at least nodeModules. Anyway thanks for the amazing answer (: – Swearingen

The only down side of putting it in the node_modules folder is that it makes it harder to nuke (rm -rf node_modules) folder – Purpura

@Purpura Not that much harder: git clean -dx node_modules – Malvern

Or in case you've forgotten the git clean syntax, one can always rm -rf node_modules && git checkout node_modules - be sure to git stash in case there are any changes to the node_modules subdirectories. – Lytle

I like the idea of using node_modules, but not for storing the source code considering how volatile it can be. Wouldn't it make more sense to publish the separated module and save it as a dependency in the original project? It provides a clear solution to the volatility of the node_modules directory and only relies on npm, rather than relying on git, symbolic links, or the $NODE_PATH solution. – Circumlunar

I feel like this would be tantamount to moving my entire src and test trees into node_modules. I'd like to resolve the problem of having things like test/devices/computer/apple/mac.js refer to src/devices/computer/apple/mac.js without relying on a relative path like ../../../../src/devices/computer/apple/mac.js but without moving that code to node_modules or using a symlink (because they are a pain in Windows and this a cross-platform project). Could I make some sort of index file that goes there instead and references + exports everything else? (i.e. like @cronvel's solution) – Sacral

@iX3 The cleanest solution that I found (if you transpile the source with babel) is github.com/tleunen/babel-plugin-module-alias – Dissimilate

Thx @PaoloMoretti, I was trying out something similar with app-module-path but running into problems because __dirname is not always the root folder (e.g. when mocha is running tests). I will try out this babel-based one. I wasn't using babel for this project but wouldn't mind adding it if it also helps simplify this. – Sacral

If you are using a transpiler like babel, I have a followup answer below at stackoverflow.com/a/44708813 – Aguila

NODE_PATH looks like the way to go. "your application will only work when your environment is setup correctly" this is always true! Isn't it easier to get the environment setup (usually in one file) than to change every import in every file? – Oared

The "put your code in node_modules and ignore all other modules" trick doesn't seem to work anymore. When I tried this on npm 6, a simple npm i decided to delete anything in node_modules that wasn't needed according to package.json, as though I had done npm i && npm prune. – Jugular

@Jugular Yeah, I think you'll have to create a script that creates all the symlinks in node_modules and run it on scripts.postinstall / scripts.postuninstall. To be fair, I should probably update this answer, because I think that yarn's workspaces are a better solution now. – Dissimilate

In the corporate world, avoiding Windows is very difficult. I love symlinks but portability should be highly sought after in a team. – Cords

@Cords I work on Windows since1998 and I'm using symlinks with mklink. Check this article. In our days, I work most of the Nodejs projects inside WSL and this makes lots of things easier. – Cyclic

Related: What do we do with answers that are entirely copied and improperly attributed (only a "reference" link or similar is included)? – Katekatee

Answer 4

I like to make a new node_modules folder for shared code. Then let Node.js and 'require' do what they do best.

For example:

- node_modules // => these are loaded from your *package.json* file
- app
  - node_modules // => add node-style modules
    - helper.js
  - models
    - user
    - car
- package.json
- .gitignore

For example, if you're in car/index.js you can require('helper') and Node.js will find it!

How node_modules Work

Node.js has a clever algorithm for resolving modules that is unique among rival platforms.

If you require('./foo.js') from /beep/boop/bar.js, Node.js will look for ./foo.js in /beep/boop/foo.js. Paths that start with a ./ or ../ are always local to the file that calls require().

If, however, you 'require' a non-relative name such as require('xyz') from /beep/boop/foo.js, Node.js searches these paths in order, stopping at the first match and raising an error if nothing is found:

/beep/boop/node_modules/xyz
/beep/node_modules/xyz
/node_modules/xyz

For each xyz directory that exists, Node.js will first look for a xyz/package.json to see if a "main" field exists. The "main" field defines which file should take charge if you require() the directory path.

For example, if /beep/node_modules/xyz is the first match and /beep/node_modules/xyz/package.json has:

{
  "name": "xyz",
  "version": "1.2.3",
  "main": "lib/abc.js"
}

then the exports from /beep/node_modules/xyz/lib/abc.js will be returned by require('xyz').

If there is no package.json or no "main" field, index.js is assumed:

/beep/node_modules/xyz/index.js

Improvised

great explanation on how it works when loading a module – Vista

This is a very elegant solution, avoids all the problems in the answers above. Should be consider THE answer, imho. – Ropedancer

running npm install deletes the inner node modules... – Glucosuria

@Glucosuria is it true? Can you provide source? – Meridel

Answer 5

The big picture

It seems "really bad" but give it time. It is, in fact, really good. The explicit require()s give a total transparency and ease of understanding that is like a breath of fresh air during a project life cycle.

Think of it this way: You are reading an example, dipping your toes into Node.js and you've decided it is "really bad IMO." You are second-guessing leaders of the Node.js community, people who have logged more hours writing and maintaining Node.js applications than anyone. What is the chance the author made such a rookie mistake? (And I agree, from my Ruby and Python background, it seems at first like a disaster.)

There is a lot of hype and counter-hype surrounding Node.js. But when the dust settles, we will acknowledge that explicit modules and "local first" packages were a major driver of adoption.

The common case

Of course, node_modules from the current directory, then the parent, then grandparent, great-grandparent, etc. is searched. So packages you have installed already work this way. Usually you can require("express") from anywhere in your project and it works fine.

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. Packages are very simple: move your files into node_modules/ and put a package.json there. Voila! Everything in that namespace is accessible from your entire project. Packages are the correct way to get your code into a global namespace.

Other workarounds

I personally don't use these techniques, but they do answer your question, and of course you know your own situation better than I.

You can set $NODE_PATH to your project root. That directory will be searched when you require().

Next, you could compromise and require a common, local file from all your examples. That common file simply re-exports the true file in the grandparent directory.

examples/downloads/app.js (and many others like it)

var express = require('./express')

examples/downloads/express.js

module.exports = require('../../')

Now when you relocate those files, the worst-case is fixing the one shim module.

Furie

So early in the Node.js life cycle, it is too soon to call anything "bad." If it works for you, if it helps you ship your product, then it is good. So your examples are good! (To me, the only thing to avoid is $NODE_PATH since it works outside the app, before the app runs.) The Python community has built its values of "being pythonic" and "there's one obvious way to do it"; and the Node.js community is coalescing on the value of "ship it now, worry about maintenance later." – Furie

I agree that the Node.js guys must have chosen relative require for a reason. I just can't see its advantages, neither from your answer. It still feels "bad" to me ;) – Honora

“You are second-guessing leaders of the Node.js community” - Same leaders decided to use callbacks instead of futures/promises. Majority of my nodejs consulting involves cursing said "leaders", and convincing people to move to JVM. Which is much easier after few months of using nodejs :) – Northerner

@nirth, move to JVM? For God's sake, why? – Shellishellie

@Shellishellie Scala and Clojure :) Though for current project we've decided to go with Python. – Northerner

Still problem in 2014: lostechies.com/derickbailey/2014/02/20/… I would like to go to browserify but the relative require hell just don't want to go away... – Swearingen

"You are second-guessing leaders of the Node.js community" please avoid this thought-discouraging tone. – Slub

Damn right he's second guessing node leaders. That's how the industry progresses. If the node guys didn't second guess the leaders that propped up thread based concurrency models, we wouldn't have node. – Hamlani

I've "give it time", almost 4 years after (now 2016) many code bases I've read, have this messy "../../../" in many places, but more especially in the test files. They are all trying to get rid of it... Also "You are second-guessing leaders of the Node.js community, people who have logged more hours writing and maintaining Node.js applications than anyone" is a common "appeal to authority" fallacy ("You said that because an authority thinks something, it must therefore be true."), check yourlogicalfallacyis.com/appeal-to-authority for more. – Swearingen

Answer 6

If you are using yarn instead of npm you can use workspaces.

Let's say I have a folder services I wish to require more easily:

.
├── app.js
├── node_modules
├── test
├── services
│   ├── foo
│   └── bar
└── package.json

To create a Yarn workspace, create a package.json file inside the services folder:

{
  "name": "myservices",
  "version": "1.0.0"
}

In your main package.json add:

"private": true,
"workspaces": ["myservices"]

Run yarn install from the root of the project.

Then, anywhere in your code, you can do:

const { myFunc } = require('myservices/foo')

instead of something like:

const { myFunc } = require('../../../../../../services/foo')

Sheilahshekel

Perhaps it's an idea to clarify that this only works for yarn, not for npm? I reckoned it would probably work for npm as well, so spent a little time wondering what I'd done wrong until I tried using yarn instead. Might've been a stupid assumption, but perhaps I'm not the only one. – Iceblink

I've edited a bit to clarify. Sorry for the confusion. – Sheilahshekel

isn't this is only as good as your team's ability to work together? (; Maybe I am being silly but if you do this and your teammates use npm (happens all the time, v annoying, +1 for npm) wouldn't this break the build? Just a guess if "workspaces" are proprietary. I would handle this with webpack and your eslint config... – Adolfoadolph

@Adolfoadolph I suppose you do have to agree to use Yarn but you kinda need to make this decision regardless - just installing packages using a mix of npm and yarn makes a mess. – Sheilahshekel

I came across this post to force npm/yarn: freecodecamp.org/news/how-to-force-use-yarn-or-npm – Sheilahshekel

npm 7 understands workspaces, too. – Christan

Answer 7

Have a look at node-rfr.

It's as simple as this:

var rfr = require('rfr');
var myModule = rfr('projectSubDir/myModule');

Kimon

i think the second line should be var myModule = rfr('/projectSubDir/myModule'); – Volcanic

From the docs : var module2 = rfr('lib/module2'); // Leading slash can be omitted. – Razee

I tried it and it rfr works OK to execute with node, but it breaks code navigation with VS Code... I haven't been able to find a workaround, to be able to use autocomplete in VS... – Money

Answer 8

I use process.cwd() in my projects. For example:

var Foo = require(process.cwd() + '/common/foo.js');

It might be worth noting that this will result in requireing an absolute path, though I have yet to run into issues with this.

Analyzer

That's bad idea because CWD does not have to be the same directory where is the application saved. – Discordancy

Works great if you set it once: global.dir = process.cwd(); then reference that anywhere. – Varve

Answer 9

IMHO, the easiest way is to define your own function as part of GLOBAL object. Create projRequire.js in the root of you project with the following contents:

var projectDir = __dirname;

module.exports = GLOBAL.projRequire = function(module) {
  return require(projectDir + module);
}

In your main file before requireing any of project-specific modules:

// init projRequire
require('./projRequire');

After that following works for me:

// main file
projRequire('/lib/lol');

// index.js at projectDir/lib/lol/index.js
console.log('Ok');

---

@Totty, I've comed up with another solution, which could work for case you described in comments. Description gonna be tl;dr, so I better show a picture with structure of my test project.

Attack

well, until now this seems the best way to do it. I do: GLOBAL.requires = require('r').r; in my index.js file. But I have a problem in my vows tests, they don't run index.js so my tests fails because requireS it's undefined. Anyway for now I can add GLOBAL.requires = require('r').r; at the top of every test. any better idea? github.com/totty90/production01_server/commit/… – Swearingen

for non test files: github.com/totty90/production01_server/blob/global-require/…, in each test file: github.com/totty90/production01_server/blob/global-require/test/… – Swearingen

the problem happens when I'm in the "pathes-test/node_modules/other.js" and I require the "pathes-test/node_modules/some.js". I should require('./some') instead of require("prj/some"). And in this way all my app would be in the node_modules dir? – Swearingen

@Totty, no problem requiring prj/some from prj/other (just tested require('prj/some'). All you app's common modules can go there (e.g. database layer). Will make no difference where your, let's say, lib is. Try and see if it's suits. – Attack

yest, I've updated it: github.com/totty90/production01_server/tree/master/node_modules/… that worked great. But I can put all my files up one level without using the node_modules? – Swearingen

Answer 10

Assuming your project root is the current working directory, this should work:

// require built-in path module
path = require('path');

// require file relative to current working directory
config = require( path.resolve('.','config.js') );

Shuler

config = require('./config.js'); is valid too. – Letourneau

@Letourneau no that's just relative to the file requiring. – Shuler

Answer 11

There's a good discussion of this issue here.

I ran into the same architectural problem: wanting a way of giving my application more organization and internal namespaces, without:

• mixing application modules with external dependencies or bothering with private npm repos for application-specific code
• using relative requires, which make refactoring and comprehension harder
• using symlinks or changing the node path, which can obscure source locations and don't play nicely with source control

In the end, I decided to organize my code using file naming conventions rather than directories. A structure would look something like:

• npm-shrinkwrap.json
• package.json
• node_modules
  • ...
• src
  • app.js
  • app.config.js
  • app.models.bar.js
  • app.models.foo.js
  • app.web.js
  • app.web.routes.js
  • ...

Then in code:

var app_config = require('./app.config');
var app_models_foo = require('./app.models.foo');

or just

var config = require('./app.config');
var foo = require('./app.models.foo');

and external dependencies are available from node_modules as usual:

var express = require('express');

In this way, all application code is hierarchically organized into modules and available to all other code relative to the application root.

The main disadvantage is of course that in a file browser, you can't expand/collapse the tree as though it was actually organized into directories. But I like that it's very explicit about where all code is coming from, and it doesn't use any 'magic'.

Matherly

From the gist you linked, solution #7, "The Wrapper", is quite simple and convenient. – Handpick

I see one more little convenience - "moving" a file to different "folder" becomes a rename - which is more easy than moving file. Plus I tend to notice that after half hour of work on project, almost all of my app tree is expanded anyway. Adding 1 level of folder space can make big codebase manageble and not introducing too much ../x/x which is already readable. – Cavan

You are reinventing folders, using dots instead of slashes, to overcome a clear lack in nodejs. – Bayly

For a small project I think this is an elegant solution. If you work in a team though it can be hard to keep straight when it is best to use this convention. – Cords

Answer 12

I have tried many of these solutions. I ended up adding this to the top of my main file (e.g. index.js):

process.env.NODE_PATH = __dirname;
require('module').Module._initPaths();

This adds the project root to the NODE_PATH when the script is loaded. The allows me to require any file in my project by referencing its relative path from the project root such as var User = require('models/user'). This solution should work as long as you are running a main script in the project root before running anything else in your project.

Contumacy

Answer 13

Some of the answers are saying that the best way is to add the code to the node_modules folder folder as a package. I agree and it's probably the best way to lose the ../../../ in require, but none of them actually give a way to do so.

From version 2.0.0, you can install a package from local files, which means you can create a folder in your root with all the packages you want,

-modules
 --foo
 --bar
-app.js
-package.json

so in package.json you can add the modules (or foo and bar) as a package without publishing or using an external server like this:

{
  "name": "baz",
  "dependencies": {
    "bar": "file: ./modules/bar",
    "foo": "file: ./modules/foo"
  }
}

After that you do npm install, and you can access the code with var foo = require("foo"), just like you do with all the other packages.

More information can be found on package.json.

And here is how to create a package: Creating Node.js modules

Revert

"This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing packages to the public registry." – Malvinamalvino

Answer 14

You could use a module I made, Undot. It is nothing advanced, just a helper so you can avoid those dot hell with simplicity.

Example:

var undot = require('undot');
var User = undot('models/user');
var config = undot('config');
var test = undot('test/api/user/auth');

Nagari

Not works in tests. If my file is /myapp/org/acme/core/AnnotationHelperTest.js I get this error: /myapp/org/acme/node_modules/mocha/bin/org/acme/core/AnnotationHelperTest.js does not exist :( – Dor

Answer 15

Another answer:

Imagine this folders structure:

• node_modules - lodash

• src - subdir - foo.js - bar.js - main.js

• tests

  - test.js
  

Then in test.js, you need to require files like this:

const foo = require("../src/subdir/foo");
const bar = require("../src/subdir/bar");
const main = require("../src/main");
const _ = require("lodash");

and in main.js:

const foo = require("./subdir/foo");
const bar = require("./subdir/bar");
const _ = require("lodash");

Now you can use babel and the babel-plugin-module-resolver with this .babelrc file to configure two root folders:

{
    "plugins": [
        ["module-resolver", {
            "root": ["./src", "./src/subdir"]
        }]
    ]
}

Now you can require files in the same manner in tests and in src:

const foo = require("foo");
const bar = require("bar");
const main = require("main");
const _ = require("lodash");

And if you want use the ES6 module syntax:

{
    "plugins": [
        ["module-resolver", {
            "root": ["./src", "./src/subdir"]
        }],
        "transform-es2015-modules-commonjs"
    ]
}

then you import files in tests and src like this:

import foo from "foo"
import bar from "bar"
import _ from "lodash"

Nunn

Thank you for this post. Now I'm able to use absolute paths in my Node app. However, I'm not sure if transform-es2015-modules-commonjs (or, @babel/plugin-transform-modules-commonjs) is necessary. Babel is meant to making sure that ES6+ features will be available for an older environment/browser, right? So I feel that it would be redundant. (In fact, my app can use es6 module syntax like import without it) FYI I'm using Node v12.2.0 – Rawley

@Rawley NodJS didn't have a support for es6 module syntax import when i answered. So transform-es2015-modules-commonj was required to execute tests on a nodeJS environment – Nunn

Answer 16

Manual Symlinks (and Windows Junctions)

Couldn't the examples directory contain a node_modules with a symbolic link to the root of the project project -> ../../ thus allowing the examples to use require('project'), although this doesn't remove the mapping, it does allow the source to use require('project') rather than require('../../').

I have tested this, and it does work with v0.6.18.

Listing of project directory:

$ ls -lR project
project:
drwxr-xr-x 3 user user 4096 2012-06-02 03:51 examples
-rw-r--r-- 1 user user   49 2012-06-02 03:51 index.js

project/examples:
drwxr-xr-x 2 user user 4096 2012-06-02 03:50 node_modules
-rw-r--r-- 1 user user   20 2012-06-02 03:51 test.js

project/examples/node_modules:
lrwxrwxrwx 1 user user 6 2012-06-02 03:50 project -> ../../

The contents of index.js assigns a value to a property of the exports object and invokes console.log with a message that states it was required. The contents of test.js is require('project').

Automated Symlinks

The problem with manually creating symlinks is that every time you npm ci, you lose the symlink. If you make the symlink process a dependency, viola, no problems.

The module basetag is a postinstall script that creates a symlink (or Windows junction) named $ every time npm install or npm ci is run:

npm install --save basetag

node_modules/$ -> ..

With that, you don't need any special modification to your code or require system. $ becomes the root from which you can require.

var foo = require('$/lib/foo.js');

If you don't like the use of $ and would prefer # or something else (except @, which is a special character for npm), you could fork it and make the change.

Note: Although Windows symlinks (to files) require admin permissions, Windows junctions (to directories) do not need Windows admin permissions. This is a safe, reliable, cross-platform solution.

Mylan

can you show the sourcecode of your test please? well, and It would work if I would have to require('project.a') this way? – Swearingen

What do you mean by require('project.a')? I think that might mean require('project/a'), although require('project').a is also possible? – Mylan

but with your example I would need to create those folders in each folder where there is a module that needs the require method. Anyway you would need to take care about the times of "../" depending of the folder. – Swearingen

Actually the link would only need to be in a node_modules directory in the closest parent of both of the file and the link would then be the same for both. See nodejs.org/api/… – Mylan

And would be relative from that location. For example: project/node_modules/project -> ../. – Mylan

Symlinks would break cross-compatibility wouldn't they? – Onset

@Onset Yes, it might not work on Windows. I assumed a UNIX-like OS with a file-system that has symbolic links was in use as the question didn't specific that it had to work on Windows. – Mylan

Re Windows Junctions: NTFS junction points, presumably. They are not necessarily the same thing. – Katekatee

Answer 17

You could define something like this in your app.js:

requireFromRoot = (function(root) {
    return function(resource) {
        return require(root+"/"+resource);
    }
})(__dirname);

and then anytime you want to require something from the root, no matter where you are, you just use requireFromRoot instead of the vanilla require. Works pretty well for me so far.

Jinnah

Thanks! I think this is pretty smart and straightforward. – Jesuit

Forgive me father, for I have sinned. I ported this to ES6 and got the following: requireFromRoot = ((root) => (resource) => require(`${root}/${resource}`))(__dirname);. Love the solution, but do you really have to bind __dirname like that? – Housewares

My memory is a bit hazy on this, but I believe __dirname changes value depending on which file it's used within. Now it may be that since the function is defined in a single place but used in multiple places, the value would remain constant even without this binding, but I just did that to ensure that this is in fact the case. – Jinnah

did this a long time ago, causes pains in testing envs and the like. not worth the overhead. random new global makes new people uncertain bla bla – Southwest

And how do you require this function? – Troat

@DarkoMaksimovic if it is global, you can just use it – Upholstery

Answer 18

Imho the easiest way to achieve this is by creating a symbolic link on app startup at node_modules/app (or whatever you call it) which points to ../app. Then you can just call require("app/my/module"). Symbolic links are available on all major platforms.

However, you should still split your stuff in smaller, maintainable modules which are installed via npm. You can also install your private modules via git-url, so there is no reason to have one, monolithic app-directory.

Sabina

Support on Windows requires more in-depth knowledge of Node and the OS. It can limit the widespread use of an open source project. – Ingleside

Generally I wouldn't use this pattern for a library (which most open source projects are). However, it is possible to create these symlinks in the npm build hook so there is no in-depth knowledge required by the user. – Sabina

Sure, but Node.js on Windows does not support symlinks by default. – Ingleside

Answer 19

In your own project you could modify any .js file that is used in the root directory and add its path to a property of the process.env variable. For example:

// in index.js
process.env.root = __dirname;

Afterwards you can access the property everywhere:

// in app.js
express = require(process.env.root);

Raillery

when multiple modules (or your module used in another app) use this same approach, the process.env.root gets rewritten (meaning that it only works if you assume your project is the only one that uses this approach in all npm packages – Rose

Answer 20

I just came across this article which mentions app-module-path. It allows you to configure a base like this:

require('app-module-path').addPath(baseDir);

Dejesus

Answer 21

I was looking for the exact same simplicity to require files from any level and I found module-alias.

Just install:

npm i --save module-alias

Open your package.json file, here you can add aliases for your paths, for e.g.

"_moduleAliases": {
 "@root"      : ".", // Application's root
 "@deep"      : "src/some/very/deep/directory/or/file",
 "@my_module" : "lib/some-file.js",
 "something"  : "src/foo", // Or without @. Actually, it could be any string
}

And use your aliases by simply:

require('module-alias/register')
const deep = require('@deep')
const module = require('something')

Voltmeter

It only works with CommonJS (ie. require) imports, not with ESM (ie. import) ones: github.com/ilearnio/module-alias/issues/59 – Toreador

Answer 22

If anyone's looking for yet another way to get around this problem, here's my own contribution to the effort:

https://www.npmjs.com/package/use-import

The basic idea: you create a JSON file in the root of the project that maps your filepaths to shorthand names (or get use-automapper to do it for you). You can then request your files/modules using those names. Like so:

var use = require('use-import');
var MyClass = use('MyClass');

So there's that.

Bertabertasi

Answer 23

What I like to do is leverage how Node.js loads from the node_modules directory for this.

If one tries to load the module "thing", one would do something like

require('thing');

Node.js will then look for the 'thing' directory in the 'node_modules' directory.

Since the node_modules folder is normally at the root of the project, we can leverage this consistency. (If node_modules is not at the root, then you have other self-induced headaches to deal with.)

If we go into the directory and then back out of it, we can get a consistent path to the root of the Node.js project.

require('thing/../../');

Then if we want to access the /happy directory, we would do this:

require('thing/../../happy');

Though it is quite a bit hacky, however I feel if the functionality of how node_modules load changes, there will be bigger problems to deal with. This behavior should remain consistent.

To make things clear, I do this, because the name of module does not matter.

require('root/../../happy');

I used it recently for Angular 2. I want to load a service from the root.

import {MyService} from 'root/../../app/services/http/my.service';

Ytterbite

About your Angular reference, with a standard CLI application, you can simply import src/app/my.service, you can also configure VSC to use non-relative imports for typescript files. – Enrol

Answer 24

I wrote this small package that lets you require packages by their relative path from project root, without introducing any global variables or overriding node defaults

https://github.com/Gaafar/pkg-require

It works like this

// create an instance that will find the nearest parent dir containing package.json from your __dirname
const pkgRequire = require('pkg-require')(__dirname);

// require a file relative to the your package.json directory 
const foo = pkgRequire('foo/foo')

// get the absolute path for a file
const absolutePathToFoo = pkgRequire.resolve('foo/foo')

// get the absolute path to your root directory
const packageRootPath = pkgRequire.root()

Austenite

Sometimes I have private packages in the main project, this script will break with that. In addition to that I'm not sure will work fine with webpack (in case you use webpack with node.js as I do) – Swearingen

If you have nested directories with package files, each dir will only be able to require files within its package. Is't that the behavior you want? I haven't tested with webpack. – Austenite

This worked perfectly for a simple project and is far easier than any of the other answers. – Obstinacy

Answer 25

I just want to follow up on the great answer from Paolo Moretti and Browserify. If you are using a transpiler (e.g., babel, typescript) and you have separate folders for source and transpiled code like src/ and dist/, you could use a variation of the solutions as

node_modules

With the following directory structure:

app
  node_modules
    ... // Normal npm dependencies for app
  src
    node_modules
      app
        ... // Source code
  dist
    node_modules
      app
        ... // Transpiled code

You can then let Babel, etc. to transpile the src directory to the dist directory.

Symbolic link

Using a symbolic link, we can get rid some levels of nesting:

app
  node_modules
    ... // Normal npm dependencies for app
  src
    node_modules
      app // Symbolic links to '..'
    ... // Source code
  dist
    node_modules
      app // Symbolic links to '..'
    ... // Transpiled code

A caveat with babel --copy-files: The --copy-files flag of babel does not deal with symbolic links well. It may keep navigating into the .. symlink and recursively seeing endless files. A workaround is to use the following directory structure:

app
  node_modules
    app // Symbolic link to '../src'
    ... // Normal npm dependencies for app
  src
    ... // Source code
  dist
    node_modules
      app // Symbolic links to '..'
    ... // Transpiled code

In this way, code under src will still have app resolved to src, whereas Babel would not see symlinks anymore.

Aguila

Thanks but, I would not recommend doing this magic. First you will lose all the imports, they won't be calculated by your IDE. If you use other tools like flow type it won't work properly either. – Swearingen

Actually flow seems to work in my case, which is not surprising since the solutions depend on the standard node module resolution model, and symlinks. So it is not really magic for tools like flow to understand. But IDEs are different. – Aguila

Answer 26

I had the same problem many times. This can be solved by using the basetag npm package. It doesn't have to be required itself, only installed as it creates a symlink inside node_modules to your base path.

const localFile = require('$/local/file')
// instead of
const localFile = require('../../local/file')

Using the $/... prefix will always reference files relative to your apps root directory.

Source: How I created basetag to solve this problem

Criswell

Answer 27

Using the "Imports" property

As of March 2023, a good way to eliminate the NodeJS relative paths is to use the imports property in package.json. For more information, please refer to this post:

• How to import JavaScript files in NodeJS using file paths from project root?.

In the codes below, #root is the project root.

(Please kindly upvote this answer and this post if they help you. Thanks!)

For CommonJS-style JavaScripts:

// package.json
{
  "imports": {
    "#root/*.js": "./*.js"
  }
}

// main.js:
const Source = require('#root/path/to/Source.js');

// Source.js:
module.exports = class Source {
  // ...
}

For ECMAScript-style JavaScripts:

// package.json:
{
  "type" : "module",
  "imports": {
    "#root/*.js": "./*.js"
  }
}

// main.js
import { Source } from '#root/path/to/Source.js';

// Source.js:
export class Source {
  // ...
}

Advantages:

• No need to "import" or "require" any additional packages (No Babel.js, No Webpack, No RequireJS). After installing NodeJS, this method works out of the box.

• IDE linkages work as expected (Ctrl-click a class name to jump directly to the source file. Also, moving the source file (by drag and drop) will automatically update the file path references. Tested on WebStorm 2022.3.2 and VS Code 1.76.2.)

• Works with both .mjs (ECMAScript module system) and .cjs (CommonJS) file types. Please see this reference Post on .cjs and .mjs.

• No need to modify with the reserved node_modules directory

• No need to set up any linux file links at the OS level

Gilliette

Answer 28

I created a node module called rekuire.

It allows you to 'require' without the use of relative paths.

It is super easy to use.

Lexicologist

Answer 29

We are about to try a new way to tackle this problem.

Taking examples from other known projects like Spring Framework and Guice, we will define a "context" object which will contain all the "require" statement.

This object will then be passed to all other modules for use.

For example,

var context = {}

context.module1 = require("./module1")( { "context" : context } )
context.module2 = require("./module2")( { "context" : context } )

This requires us to write each module as a function that receives opts, which looks to us as a best practice anyway...

module.exports = function(context){ ... }

And then you will refer to the context instead of requiring stuff.

var module1Ref = context.moduel1;

If you want to, you can easily write a loop to do the 'require' statements

var context = {};
var beans = {"module1" : "./module1","module2" : "./module2" };
for ( var i in beans ){
    if ( beans.hasOwnProperty(i)){
         context[i] = require(beans[i])(context);
    }
};

This should make life easier when you want to mock (tests) and also solves your problem along the way while making your code reusable as a package.

You can also reuse the context initialization code by separating the beans declaration from it.

For example, your main.js file could look like so

var beans = { ... }; // like before
var context = require("context")(beans); // This example assumes context is a node_module since it is reused..

This method also applies to external libraries, and there isn't any need to hard code their names every time we require them. However, it will require a special treatment as their exports are not functions that expect context...

Later on, we can also define beans as functions—which will allow us to require different modules according to the environment—but that it out of this question's scope.

Scopolamine

Answer 30

I was having trouble with this same issue, so I wrote a package called include.

Include handles figuring out your project's root folder by way of locating your package.json file, then passes the path argument you give it to the native require() without all of the relative path mess. I imagine this not as a replacement for require(), but a tool for requiring handling non-packaged / non-third-party files or libraries. Something like

var async = require('async'),
    foo   = include('lib/path/to/foo')

Static

Answer 31

If your app's entry point js file (i.e. the one you actually run "node" on) is in your project root directory, you can do this really easily with the rootpath npm module. Simply install it via

npm install --save rootpath

...then at the very top of the entry point js file, add:

require('rootpath')();

From that point forward all require calls are now relative to project root - e.g. require('../../../config/debugging/log'); becomes require('config/debugging/log'); (where the config folder is in the project root).

Debroahdebs

Answer 32

In simple lines, you can call your own folder as module:

For that we need: global and app-module-path module

Here "App-module-path" is the module. It enables you to add additional directories to the Node.js module search path. And "global" is anything that you attach to this object will be available everywhere in your app.

Now take a look at this snippet:

global.appBasePath = __dirname;

require('app-module-path').addPath(appBasePath);

__dirname is the current running directory of Node.js. You can give your own path here to search the path for module.

Illiquid

Answer 33

If you're using ES5 syntax you may use asapp. For ES6 you may use babel-plugin-module-resolver using a config file like this:

.babelrc

{
  "plugins": [
    ["module-resolver", {
      "root": ["./"],
      "alias": {
        "app": "./app",
        "config": "./app/config",
        "schema": "./app/db/schemas",
        "model": "./app/db/models",
        "controller": "./app/http/controllers",
        "middleware": "./app/http/middleware",
        "route": "./app/http/routes",
        "locale": "./app/locales",
        "log": "./app/logs",
        "library": "./app/utilities/libraries",
        "helper": "./app/utilities/helpers",
        "view": "./app/views"
      }
    }]
  ]
}

Wayfarer

Answer 34

Some time ago, I created a module for loading modules relative to pre-defined paths.

https://github.com/raaymax/irequire

You can use it instead of 'require'.

irequire.prefix('controllers',join.path(__dirname,'app/master'));
var adminUsersCtrl = irequire("controllers:admin/users");
var net = irequire('net');

Bristle

Answer 35

Whilst these answers work, they do not address the problem with npm test.

If, for example, I create a global variable in server.js, it will not be set for my test suite execution.

To set a global appRoot variable that will avoid the ../../../ problem and will be available in both npm start and npm test, see:

Mocha tests with extra options or parameters

Note that this is the new official Mocha solution.

Nolly

If you don't use globals - like a good developer - it works fine. I don't like adding bootstrap to my projects, it's a recepie for global abuse. – Concrescence

Answer 36

Try using asapp:

npm install --save asapp

var { controller, helper, middleware, route, schema, model, APP, ROOT } = require('asapp')

controller('home') instead require('../../controllers/home)

Wayfarer

Answer 37

My method of achieving this is to create "local link modules".

Take for example the folder structure of

db ¬
    models ¬
        index.js
    migrations
    seed
    config.json

routes ¬
    index.js
    user ¬
        index.js

If from ./routes/user/index.js I want to access /db/models/index.js, I'd be writing:

require('../../db/models/index.js')

To make the /db/models/index.js accessible from everywhere, I create a folder inside the db folder named _module_, this contains a package.json and a main.js file.

# package.json
{
    "name": "db", <-- change this to what you want your require name to be
    "version": "1.0.0",
    "description": "",
    "author": "",
    "repository": {},
    "main": "main.js"
}

// main.js
module.exports = require('../../db/models/index');

The path in main.js must be relative as if the file is in node_modules, like

node_modules ¬
    db ¬
        main.js

You can then run npm install ./db/_module_ and this will copy the files in ./db/_module_ to ./node_modules/db creating an entry under dependencies in the app's package.json like

"db": "file:db/_module_"

You can now use this package from anywhere by

const db = require('db');

This automatically installs with the rest of your modules when you run npm install, works cross-platform (no symbolic links), and doesn't require any third-party packages.

Carder

Answer 38

Since none of the proposed solutions was quite as concise as I wanted, I wanted to share mine here.

I was looking for a solution that doesn't not 'require' anything additional, no modules, no package.json modifications, no environment variables, no external dependencies, minimal CPU cycles, etc.

...so I came up with this:

global.dir = process.cwd();

I do this once when the app loads. Obviously, you can modify the path by adding a subdirectory and/or adding '/..' which will send you up or down the directory tree as needed.

All my includes, in all files, are in this format:

const myFn = require(global.dir + '/js/myDir/myFn');

Varve

Answer 39

I don't think you need to solve this in the manner you described. Just use sed if you want to change the same string in a large amount of files. In your example,

find . -name "*.js" -exec sed -i 's/\.\.\/\.\.\//\.\.\//g' {} +

would have ../../ changed to ../

Alternatively, you can require a configuration file that stores a variable containing the path to the library. If you store the following as config.js in the example directory

var config = {};
config.path = '../../';

and in your example file

myConfiguration = require('./config');
express = require(config.path);

You'll be able to control the configuration for every example from one file.

It's really just personal preference.

Abrahan

well but if in one example it uses ../../ to another module in the same example and not to the root then it breaks all the code. Yes you could do the path variable but that's not a clean way to do IMO. If you move files from here to there this is not that clean. And just take a look at "../../" how descriptive that is compared to 'express'. or '../../../my/config' compared to '/my/config', there is no comparation.. – Swearingen

By the way you would have to require config in each folder you use and the same problem would happen. If you change a folder you will have to change require('./config') to require('../../config'), same problem again.. lol – Swearingen

Change the expression if you don't want it to match every occurrence of "../../". Here's one that will only match that line you provided: "s/express = require('\.\.\/\.\.\/')/express = require('\.\.\/')/" – Abrahan

this is just one module in the parent folder, but in a real world project you can't just do like that. There would be plenty of different parent folder and modules and this relative pathing it's making me crazy. In my way you could easily replace the full path to the new one across the whole project. – Swearingen

These examples aren't a real world project. In a real world project you'd have a configuration file, or an absolute path to the library that would be defined in implementation. – Abrahan

So in real world they would have a config file with the absolute path to the project root and then they do: var config = require('../../config'); var myfn = require(config.root + '/a/b/myfn');? – Swearingen

That's the jist, but if I'm developing an app using your framework, I'd have the configuration file in my app's folder alongside the app. There wouldn't be a need to store it two directories above any longer. Other JS files in my app would simply require the config file and I'd be able to update the library location for all of them through this one file. – Abrahan

well I just made a npm module that do the trick (search.npmjs.org/#/r) I put "var r = require('r').r" at the begining of each module and then all the requires will be r(...). if the first character it's ">" ex. r('>/my/sub/folder/') then it's relative to the root folder of my project. This is the best thing I could come with for now – Swearingen

Answer 40

Many good answers here already. That just shows this is a common problem without clear-cut best solution. Best would be native support in Node.js of course. Here's what I use currently:

const r  = p => require (process.cwd() + p);
let see  = r ('/Subs/SubA/someFile.js' );
let see2 = r ('/Subs/SubB/someFile2.js');
...

I like this solution because the requires-section becomes shorter, no need to type 'require' many times. The main benefit of absolute paths is you can copy them from file to file without having to adjust them like you would with relative paths. Therefore copying also the extra one-liner arrow-function 'r()' is not too much extra work either. And no need to import extra npm-dependencies just to accomplish this very simple task.

Apivorous