How to have path alias in nodejs? - node.js

Let's say i have following codes:
var mod1 = require('../../../../ok/mod1');
var mod2 = require('../../../info/mod2');
It's not pretty coding like above, i am wondering if there is a way to configure the root resolver just like webpack-resolve-root in nodejs?
So far as i know, the NODE_PATH can be used to replace the root of node_modules, but that's not what i want. I'd like to have the resolver to resolve multiple folders in order.

Updated answer for 2021.
nodejs subpath imports have been added in: v14.6.0, v12.19.0
This allows for you to add the following to package.json
"imports": {
"#ok/*": "./some-path/ok/*"
"#info/*": "./some-other-path/info/*"
},
and in your .js
import mod1 from '#ok/mod1';
import mod2 from '#info/mod2';

There is an npm package called module-alias that may do what you are looking for.

The best way to approach this would be to use a global (config) container.
In most cases you will have a config file in your application. In this config you can add a property which will be an object containing all absolute paths to files/folders.
Because config files are used at the start of you application, you just do the following:
var config = require("./config.js");
//config = {... , path: {"someModule": "/absolute/path/to", "someModule2": "/absolute/path/to"...}}
global.CONFIG_CONTAINER = config
Later on in your application you can just use
var myModule = require(CONFIG_CONTAINER.path.someModule)
// + concat if you are looking for a file
In case you have some complex paths and you need a more dynamic system, you can always implement a function inside the config that will build paths for you. ( config.makePath = function(){...} )
That should take care of it in a nutshell.

Related

How to access the base package form a node_module

I am looking to access a JSON config file that the user would place next to their package.json from a node_module package that I created. Is there a best approach to do this. I tried a relative import but that didn't really work and I am not sure how best to accomplish dynamic imports if the config file doesn't exist because I want to allow it to not exist as well.
Here is how I tried to handle dynamic imports though:
export const overrides = (function () {
try {
return require('../../../../../../overrides.json');
} catch (_err) {
return null;
}
})();
Also I tried fs but I get a browser config error I am not sure if that is something else. I should research but I didn't understand the docs around that.
using a library
This worked for me: find-package-json
Basically on any js file who needs the base, home or workspace path, do this:
var finder = require('find-package-json');
var path = require('path');
var f = finder(__dirname);
var rootDirectory = path.dirname(f.next().filename);
rootDirectory will be the location of the folder in which the main package.json exist.
If you want to optimize, get the appRootPath variable at the start of your app and store/propagate the variable to the hole nodejs system.
no libraries
Without any library, this worked for me:
console.log("root directory: "+require('path').resolve('./'));
This will get you the root directory of your nodejs app no matter if you are using npm run start or node foo/bar/index.js
More ways to get the root directory here:
Determine project root from a running node.js application
usage
If you achieve to obtain the root directory of your nodejs app and your file is at the package.json level, use this variable like this to locate any file at root level:
rootDirectory+"/overrides.json"

How to create a config file for node pkg

I use node pkg to create a .exe of my nodejs service: https://www.npmjs.com/package/pkg
My question is: how do I make the .exe use a config.js for some setup values? Basic stuff like ip, port, database name etc. Because I have 3 environments, and I would like to use the same exe for all, but different config.js files for each.
So far, if I do pkg app.js then it creates an .exe that doesn't look at any other files. Totally stand alone. How do I make it look at config.js when it is started up?
On the website they do have a section on config https://github.com/zeit/pkg#config but I do not understand how to make use of it. At the moment I have my app.js, and I have secrets.js which holds the config information.
I am not sure this is right way, but I hope this can be helpful to somebody.
Refer to pkg document, on the run time, __dirname becomes "/snapshot/project".
So, by checking __dirname, you can identify in which environment you are.
(node app.js or app.exe).
Then we can separate require sentence like below.
const PKG_TOP_DIR = 'snapshot';
const runInPKG = (function(){
const pathParsed = path.parse(__dirname);
const root = pathParsed.root;
const dir = pathParsed.dir;
const firstDepth = path.relative(root, dir).split(path.sep)[0];
return (firstDepth === PKG_TOP_DIR)
})();
let config = require('./appconfig.json');
if(runInPKG) {
const deployPath = path.dirname(process.execPath);
config = require(path.join(deployPath, 'appconfig.json'));
}
Adding above code to your app.js makes some warning when pkg build.
pkg . --targets node8-win-x64 --out-path ./dist
pkg#4.4.0
Warning Cannot resolve 'path.join(deployPath, 'appconfig.json')'
app.js
Dynamic require may fail at run time, because the requested file
is unknown at compilation time and not included into executable.
Use a string literal as an argument for 'require', or leave it
as is and specify the resolved file name in 'scripts' option.
https://github.com/vercel/pkg/issues/195
use fs to read config file insead of require or import
eg:
const configPath = path.join(process.cwd(), './config/config.json');
lset data = fs.readFileSync(configPath);
same question link:excluding config file while converting node js files to exe using pkg

Node - How can a script be sure of the location of a dependency to call? [duplicate]

I require a module that was installed via npm. I want to access a .js file subordinate to that module (so I can subclass a Constructor method in it). I can't (well, don't want to) modify the module's code, so don't have a place to extract its __dirname.
I am aware of the following question, but it is about getting the path of a module that one has code control over (hence, __dirname is the solution):
In Node.js how can I tell the path of `this` module?
~~~
Even better would be to get the module's loaded module info
If I correctly understand your question, you should use require.resolve():
Use the internal require() machinery to look up the location of a module, but rather than loading the module, just return the resolved filename.
Example: var pathToModule = require.resolve('module');
require.resolve() is a partial answer. The accepted answer may work for many node modules, but won't work for all of them.
require.resolve("moduleName") doesn't give you the directory where the module is installed; it gives you the location of the file defined in the main attribute in the module's package.json.
That might be moduleName/index.js or it could be moduleName/lib/moduleName.js. In the latter case, path.dirname(require.resolve("moduleName")) will return a directory you may not want or expect: node_modules/moduleName/lib
The correct way to get the complete path to a specific module is by resolving the filename:
let readmePath = require.resolve("moduleName/README.md");
If you just want the directory for the module (maybe you're going to make a lot of path.join() calls), then resolve the package.json — which must always be in the root of the project — and pass to path.dirname():
let packagePath = path.dirname(require.resolve("moduleName/package.json"));
FYI, require.resolve returns the module identifier according to CommonJS. In node.js this is the filename. In webpack this is a number.
In webpack situation, here is my solution to find out the module path:
const pathToModule = require.resolve('module/to/require');
console.log('pathToModule is', pathToModule); // a number, eg. 8
console.log('__webpack_modules__[pathToModule] is', __webpack_modules__[pathToModule]);
Then from __webpack_modules__[pathToModule] I got information like this:
(function(module, exports, __webpack_require__) {
eval("module.exports = (__webpack_require__(6))(85);\n\n//////////////////\n//
WEBPACK FOOTER\n// delegated ./node_modules/echarts/lib/echarts.js from dll-reference vendor_da75d351571a5de37e2e\n// module id = 8\n// module chunks = 0\n\n//# sourceURL=webpack:///delegated_./node_modules/echarts/lib/echarts.js_from_dll-reference_vendor_da75d351571a5de37e2e?");
/***/
})
Turned out I required old scripts from previous dll build file(for faster build speed), so that my updated module file didn't work as I expected. Finally I rebuilt my dll file and solved my problem.
Ref: Using require.resolve to get resolved file path (node)
Jason's answer was the best answer, until Node.js ESM and the exports field came out.
Now that Node supports packages with an exports field that by default will prevent files like package.json from being resolvable unless the package author explicitly decides to expose them, the trick in Jason's answer will fail for packages that do not explicitly expose package.json.
There is a package called resolve-package-path that does the trick.
Here's how to use it:
const resolvePkg = require('resolve-package-path')
console.log(resolvePkg('#some/package'))
which will output something like
/path/to/#some/package/package.json
regardless of what the package's exports field contains.
I hope I correctly understand your needs: to get entry point file of some module. Let's say you want to get entry point of jugglingdb module:
node
> require('module')._resolveFilename('jugglingdb')
'/usr/local/lib/node_modules/jugglingdb/index.js'
As you can see this is not "official" way to get this kind of information about module, so behavior of this function may change from version to version. I've found it in node source: https://github.com/joyent/node/blob/master/lib/module.js#L280
According to #anatoliy solution, On MacOS X I have found the lookup paths doing
require('module')._resolveLookupPaths('myModule')
so I get the resolved lookup paths
[ 'myModule',
[ '/Users/admin/.node_modules',
'/Users/admin/.node_libraries',
'/usr/local/lib/node' ] ]
whereas the
require('module')._resolveFilename('myModule')
will not resolve the module I was looking for anyways, in fact the crazy thing is that the _load will not resolve the module:
> require('module')._load('myModule')
Error: Cannot find module 'myModule'
at Function.Module._resolveFilename (module.js:440:15)
at Function.Module._load (module.js:388:25)
at repl:1:19
at sigintHandlersWrap (vm.js:32:31)
at sigintHandlersWrap (vm.js:96:12)
at ContextifyScript.Script.runInContext (vm.js:31:12)
at REPLServer.defaultEval (repl.js:308:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
at REPLServer.<anonymous> (repl.js:489:10)
while the require will:
> require('myModule')
but I don't have this module in
myProject/node_modules/
myProject/node_modules/#scope/
/usr/local/lib/node_modules/
/usr/local/lib/node_modules/#scope
/usr/local/lib/node_modules/npm/node_modules/
/usr/local/lib/node_modules/npm/node_modules/#scope
$HOME/.npm/
$HOME/.npm/#scope/
so where is this module???
First I had to do a $ sudo /usr/libexec/locate.updatedb
Then after some coffee I did locate myModule or better locate myModule/someFile.js
et voilà, it comes out that it was in a parent folder of my project i.e. outside my project root folder:
$pwd
/Users/admin/Projects/Node/myProject
$ ls ../../node_modules/myModule/
so you cannot avoid to rm -rf ../../node_modules/myModule/ and a fresh npm install.
I can argue that no one instructed npm to scan my computer in search for modules elsewhere than my project root folder where it was supposed to run or in the default modules search path.
This is maybe what you're looking for, check:
require.main.filename
Here is a solution that returns the module directory in a platform agnostic way. This does not use any 3rd party libraries and successfully locates ESM modules with "type": "module" and modules installed via npm link..
NOTE: If a particular module is a symlink to another location (eg. npm link) you will need use fs.realpath to get the location of the target directory:
const moduleDir = getModuleDir('some-npm-module');
const theRealPath = fs.realpathSync(moduleDir);
ESM
import fs from 'fs';
import path from 'path';
import { createRequire } from 'module';
/**
* Get's the file path to a module folder.
* #param {string} moduleEntry
* #param {string} fromFile
*/
const getModuleDir = (moduleEntry) => {
const packageName = moduleEntry.includes('/')
? moduleEntry.startsWith('#')
? moduleEntry.split('/').slice(0, 2).join('/')
: moduleEntry.split('/')[0]
: moduleEntry;
const require = createRequire(import.meta.url);
const lookupPaths = require.resolve.paths(moduleEntry).map((p) => path.join(p, packageName));
return lookupPaths.find((p) => fs.existsSync(p));
};
CommonJS
const fs = require('fs');
const path = require('path');
const { createRequire } = require('module');
/**
* Get's the file path to a module's folder.
* #param {string} moduleEntry
* #param {string} fromFile
*/
const getModuleDir = (moduleEntry, relativeToFile = __filename) => {
const packageName = moduleEntry.includes('/')
? moduleEntry.startsWith('#')
? moduleEntry.split('/').slice(0, 2).join('/')
: moduleEntry.split('/')[0]
: moduleEntry;
const require = createRequire(relativeToFile);
const lookupPaths = require.resolve.paths(moduleEntry).map((p) => path.join(p, packageName));
return lookupPaths.find((p) => fs.existsSync(p));
};

Best way to find the location of a specific file within a node dependency?

I'm trying to access a file contained within a node dependency. Previously I was hardcoding access to this file in the form require('../../node_modules/foo/bar.png') however this path cannot be relied upon with npm v3 as the place in the node_modules folder hierarchy where a given dependency sits may change. require.resolve doesn't seem to help me as it gives the main file within the dependency rather than just the folder of the dependency.
Assuming you're writing both modules you can use __dirname from inside the dependency to get the path the module is running from:
//foo/index.js
module.exports.root = __dirname;
Then use that to serve the files:
//server.js
var assets = require('foo');
fs.readFile(assets.root + '/bar.png', function(){/*whatever*/});
My solution is by using https://www.npmjs.com/package/dive and assert every files.
dive(directory[, options], action[, complete]);
A common solution I have found on github in various open source projects is to use findup/findup-sync, ie
var findup = require('findup-sync');
var filePath = findup('node_modules/foo/bar.png');

How to make node.js require absolute? (instead of relative)

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/
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.
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.
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
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.
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')
Have a look at node-rfr.
It's as simple as this:
var rfr = require('rfr');
var myModule = rfr('projectSubDir/myModule');
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.
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.
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'.
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') );
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.
Some of the answers is saying that the best way is to add the code to the node_module as a package, i agree and its 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 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 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 info can be found here :
https://docs.npmjs.com/files/package.json#local-paths
and here how to create a package :
https://docs.npmjs.com/getting-started/creating-node-modules
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');
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 2 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"
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.
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.
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);
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.
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.
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);
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')
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.
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()
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 src directory to dist directory.
symlink
Using symlink we can get rid some levels of nesting:
app
node_modules
... // normal npm dependencies for app
src
node_modules
app // symlinks to '..'
... // source code
dist
node_modules
app // symlinks to '..'
... // transpiled code
A caveat with babel --copy-files The --copy-files flag of babel does not deal with symlinks well. It may keep navigating into the .. symlink and recusively seeing endless files. A workaround is to use the following directory structure:
app
node_modules
app // symlink to '../src'
... // normal npm dependencies for app
src
... // source code
dist
node_modules
app // symlinks to '..'
... // transpiled code
In this way, code under src will still have app resolved to src, whereas babel would not see symlinks anymore.
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
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';
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).
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"
}
}]
]
}
I created a node module called rekuire.
It allows you to 'require' without the use of relative paths.
It is super easy to use.
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.

Resources