How to import path using ES6 module import

Question

Is there any good way to load a module elegantly (where the IDE can suggest or go into the file) using dynamic path or start from the root directory to import a module?

import * as Q from 'q';
import * as loopback from 'loopback';
import datasources from '../../../datasources.json';
import app from '../../../server';
import {ApiError, ValidationError, DatabaseError} from'../../../utils/error-handlers';

Gilles

Hack the import loader? Put a symbolic link in node_modules to your preferred default load location? Use a flatter directory structure? – Redintegration

So what does not work in the example code you posted? Or what don't you like about the code? – Brother

@Brother Code is working fine but I do not like the ../../ go to the relative directory rather I would like to go from the base directory. Suppose like have directories a->b->c from c if I want to go to b in current structure it will be '../b' rather I would like 'a/b'. – Gilles

So you mean like import app from '/server'? Your module loader is responsible for resolving those strings to modules. Check its docs about support of paths, and maybe file a feature request. – Brother

This has nothing to do with ES6. – Nymphet

@FelixKling Could you explain why it has "nothing to do with ES6" when it about using ES6 module syntax? In anycase, I cannot see how this is a duplicate. The marked duplicate is for the CommonJS case. This is for the ES6 import/export syntax case. – Redintegration

@torazaburo: ES6 does not define how a module identifier is supposed to be resolved or even what it means. All it defines is the syntax: import ... from 'moduleIdentifier';. It does not care what moduleIdentifier is. The module loader cares. In case of NodeJS, the module loader interprets the identifiers as paths or names. Which syntax you use (CommonJS or ES6) is irrelevant. If the question is whether there is specific syntax or support in ES6 then the answer is: no. The duplicate was absolutely relevant because it explained how to solve this in NodeJS (no matter the synax). – Nymphet

@FelixKling I know that. That is why in my original comment I suggested hacking the import (module) loader. In practice, ES6 toolchains such as Babel support both the import syntax and provide the loader, which is distinct from the loader used by node, meaning that solutions to "rooting" node require paths do not apply to ES6 environments. Concretely speaking, what is the solution you propose to the OP's question? – Redintegration

@torazaburo: Babel does not provide a module loader (do you mean the babel/register hack?). Anything mentioned here would work: https://mcmap.net/q/87818/-how-can-i-make-node-js-39-require-39-absolute-instead-of-relative . Why shouldn't it work with ES6 syntax? After all, Babel simply compiles to CommonJS (if you want to execute it in a Node.js environment). Anything you mentioned in your first comment is pretty much independent of the specific import syntax. – Nymphet

@torazaburo: The point that I'm trying to bring across for this and all similar questions is that how to load a module is completely independent from ES6 and as such has nothing to do with ES6. Some things don't change, even with ES6. How to use an "absolute path" to import Node modules didn't change with ES6. Even if Babel is used and someone was to implement a custom transform like mentioned here, this has nothing to do with ES6. This only has something to do with Babel. – Nymphet

Possible duplicate of Difference between simple import statement and System.import in ES6 Module Loader – Gassaway

Answer 1

The module identifier is not necessarily even a path at all. For example, it often searches the node_modules folder. The quick answer is the syntax depends on the module loader.

But the pragmatic answer, if you are using Babel (as you might be since you specified this was an ES6 import), is that you can specify a location relative to the project root with an '@' at the beginning. For example, in my Vue.js project, I have:

import PageFooter from '@/components/PageFooter'

In my case, this can avoid issues of having a complex tree of nested components, at various depths.

In your case, you could have:

import app from '@/server'

assuming server was in the project root (e.g. as server.js and not a folder itself).

Timbering