module: require relative from package root

[KoryNunn]

Hope this hasn't been raised before, i did search..

Everyone has done this:

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

Why not add a symbol that resolves to the closest package.json?

    var thing = require('^/thing');

Doesn't have to be a ^.

[silverwind]

+0 from me. If we add it, I'd rather have this in a seperate method to avoid dealing with special characters.

[KoryNunn]

totally ok with separate method. Can even omit the ./ then.

require.[root/self/local]('thing');

[jbergstroem]

I prefer a non-magic require() -- the more obvious include path the better.

[silverwind]

Could you clarify a bit what you want? ../../../../thing looks like you're requiring a file, not a package. I don't think we can reliably search for files easily.

As for packages, it should already work as expected and search the parent directories containing node_module folders.

[KoryNunn]

requiring files. especially helpful when you have a few top-level singletons, like 'services' 'router' etc.

so in ./router/public/whatever you could just grab a service via:

var myService = require.local('services/myService');

[Trott]

It would seem like proof-of-concept for this could happen in user-land as a module published to npm. And, in fact, that might be the better place for it to live permanently.

Currently, io.js has nearly no awareness of package.json. See "Folders As Modules" in the Modules documentation.

So that would have to be added in just for this functionality.

I am aware of at least two projects that have a sort of "find the root of this project" logic/module in them. The first is npm. See find-prefix.js if you might be interested in using that as a model or starting point. The other is git-validate which has a findProjectRoot() function.

[silverwind]

Ah, alright. Now I get what you meant. Maybe require.fromRoot would be an fitting name, if we decide to add it.

[KoryNunn]

@Trott yeah I was thinking a userland module would be the best way to do it, but then it's going to be an uphill battle to get things like browserify to support it (since a userland module would be digging into the extra stuff that node require has on it).

Might be possible with a browserify transform I guess..?

also, node does know about node_modules, in which case this issue could be redefined to say, go to the closes folder that contains node_modules.

[ChALkeR]

Why does this have to be in core?

Unobvious require semantics for files could introduce weird bugs when one has several files with the same name in different places.

If this was really needed, there would have been a module that does that already.
If you need this — why not just make a module?

If you base on package.json location, it means that your require statements for files change their behaviour based on the presense or absense of some other files (namely package.json).

[monsanto]

On behalf of Babel, it would be easier for our ES6 import <-> node modules interop if there was not a different require.local function. Right now we are agnostic to the format of the from string: we can assume import X from 'loc' is (roughly) var X = require('loc'). There is no way to extend this syntax for local imports except in the from string, which would bring us back to the ^ syntax that was originally suggested. On top of that, we would have to inspect this string ourselves and transpile differently depending on the format of the string.

As for the functionality itself, this is a common problem, and it would be nice to have a canonical solution to it. OTOH making a symlink isn't that big of a deal. So I guess I'm neutral.