WRT PR #3 - Import relative to package root

[mariusGundersen]

The current proposal adds support for the following path resolutions:

• import relative to node_modules (import x from 'something')
• import relative to the current file (import x from './something')
• import relative to the filesystem root (import x from '/something')

But what's missing from this list is importing relative to the current project (package) root. This is quite common in other languages, and other languages even prefer absolute imports and discourage relative imports. It's therefore unfortunate that in node we don't have the option or opportunity to decide for ourselves on a per-project basis.

The semantics are pretty straight forward: traverse the directory tree upwards from the current file looking for a folder that contains a file with the name package.json, and use this folder as root. This is pretty similar to the way the node_modules folder is found, so won't add any performance issues.

My suggestion for the syntax is to use the /something rule, and to use file:///something for absolute imports from the filesystem root. A rule of thumb in api design is that common problems should have simple solutions and uncommon problems should have solutions. I believe that importing modules from the filesystem root is uncommon, while importing modules from the package root is common, and therefore the latter should have a simpler solution than the former.

This doesn't make anything that is possible today impossible, and doesn't make it significantly more difficult to transpile or to convert CJS modules to ES modules.

[calebmer]

+1 from me. This would also probably discourage people from using NODE_PATH for this. The syntax I've seen in some configurations is:

import x from '~/something.js'

[feross]

-1. This feels like feature creep. The module system should not change at this point because it is "Stability: 3 - Locked".

Stability: 3 - Locked
Only fixes related to security, performance, or bug fixes will be accepted.
Please do not suggest API changes in this area; they will be refused.

See https://nodejs.org/api/documentation.html

[calebmer]

If we are considering changing module resolution with ES modules, this feature might be worth considering.

[mariusGundersen]

@feross, this is only for ES6 modules using import, so should fall under the same changes as proposed in #3, where there are other breaking changes that aren't just security, performance or bug fixes.

[feross]

Even so, I don't think it's a good idea. Having a deep hierarchy of files should be painful. This makes it easier to make gargantuan modules.

[mariusGundersen]

I agree that it makes it easier to make big modules, but it's up to the developer to decide how they want to structure the application. The places I really miss this feature is in the end applications, those that are not published on npm but end up being deployed to production servers.

[kgryte]

This proposal is not necessary and can already be achieved by placing application files in a top-level node_modules folder.

[hybrist]

I agree with @feross. The current system encourages clean dependency trees and code locality. Making it convenient to "randomly" reach into different parts of the project doesn't sound like an improvement.

Also, any difference in the module resolution rules between import and require would break one of the transitioning scenarios mentioned in the other thread: compiled-to-CJS code and JavaScript module code shipping in the same package. If the module resolution rules would be different between the two, it could lead to lots of breakage once people try node vX (where vX introduced module support).

[fatfisz]

@jkrems Surely "randomly" reaching into the file system is more dangerous than "randomly" reaching into the project?

[hybrist]

@fatfisz require.resolve and passing down resolved paths is a thing that's sometimes necessary. Requiring global config files from known locations isn't completely unreasonable. Sure, not a thing you'd do all the time. But I don't quite understand where you read "because complex dependency graphs are bad, loading dependencies from absolute paths has to be the greatest thing ever".

[fatfisz]

@jkrems I don't know how did you make that deduction at the end, so I'll just ignore that part.

I just see this proposal as an improvement over the current situation. I didn't have any need for requiring files globally, but there were a lot of times when I needed to reference, say, a "config" part of my project from some other part of that project. I think that quite a bit of other people also have this problem given the number of proposed "solutions" in this gist.

Requiring global config files from known locations isn't completely unreasonable. Sure, not a thing you'd do all the time.

I don't see how this isn't applicable to paths relative to the project root.

[mariusGundersen]

Also, any difference in the module resolution rules between import and require would break one of the transitioning scenarios mentioned in the other thread: compiled-to-CJS code and JavaScript module code shipping in the same package. If the module resolution rules would be different between the two, it could lead to lots of breakage once people try node vX (where vX introduced module support).

@jkrems I don't see how adding a feature to import would break things when transitioning from require. How would it break when node vX is released with a new feature that wasn't in node v(X-1)?

There are already plugins that let you compile the syntax @calebmer proposed to CJS: https://github.com/michaelzoidl/babel-root-import

[bmeck]

@calebmer import will not do searching based upon environment variables.

[bmeck]

Are there any major problems with placing links (symlink generally, junction otherwise) in node_modules/ rather than extending the module resolution algorithm?

Given the directory structure:

something/
\-  foo.js
node_modules/
\- something -> ../something

You can use:

require('something/foo.js');

[mariusGundersen]

You can't commit a symlink to git.

Sure, there are ways to get it to work, but they are convoluted and all have some gotchas you have to be careful with. The fact that many people are asking this question (see the gist @fatfisz linked to) indicates that a simple solution, with no external dependencies, is wanted.