4 ways to avoid double dots in module specifiers

Use paths relative to a Node.js project root as module specifiers

Module specifiers with double dots are a convenient feature. With a JavaScript IDE, it is easy to create a module specifier with many double dots.

Let’s consider a sample project with following layout:

In the project module file3.js depends on module shared.js:

import val from '../../../first/second/third/shared.js';

If the imported module shared.js is moved to another folder the import above, or any imaginable its alternative, has to be inevitably adjusted. There is nothing one could do.

If the importing module file3.js is moved to a folder on a different folder tree level, the number of double dots has to be adjusted in the import statement. If file3.js had many double dot-based imports then they all would have to be adjusted, which is inconvenient. But if the module specifier in file3.js was relative not to the importing file but to the project root, for example:

import val from 'first/second/third/shared.js';

it would not need to be adjusted when file3.js is moved elsewhere. So double dots complicate the mobility of the importing modules.