Repository navigation
Request: Allow specifying lookup paths for require.resolve #5963
Description
Activity
Sorry,
Moduleis locked. I don't think this can happen. I think it's worth discussing regardless.
I'm not sure I understand your particular problem, is this not something
module.require(and notrequire) would solve for you?If you don't want to
requirethe actual file - is this something amodule.require.resolvewould fix for you?require.resolvecould handle it if it could be given different lookup paths. We use the full path to various references that get passed around multiple files, so where we resolve the module path isn't the same place that we require it.If
Moduleis locked, does that mean it's safe to rely onModule._findPaths? If so, then maybe no change is needed._findPaths is an internal method, there is no gurantee regarding it as far as I know. In practice I doubt it'll break but that's not a position I'd be comfortable to have you in (relying on it).
Would you mind elaborating a little on why you need to pass the paths inside rather than using module.require ?
Sure, basically, we have a configuration structure that we build up from multiple sources. At different points during that process, we convert Node.js module names into their paths, and we
requirethose paths at different points in time. For instance, withextends, we do end up requiring fairly soon after resolving, but forparserwe do not. The value ofparseris passed along in the configuration (which contains only json-compatible data) until the very last moment before the JS code is parsed. At that point, it is bothrequired to start parsing and the path is also passed along to rules in case they want torequireit.So, changing just
requirehelps with one case but not the other.FWIW, I'd also like to bless
Module._findPath(), and will gladly submit the PR to make it happen.Putting aside the Locked status issue for now, I'd also be for it (what @cjihrig said) if we can rename it to something without a
_and keep_findPath()as an undocumented alias for backwards compatibility.Returning to the Locked status, if we have to vote to move it to Stable in the CTC or something, that's a high bar but not an entirely insurmountable obstacle. I certainly appreciate the effort here to document the use case because that should certainly be a pre-requisite for unlocking.
I think we can expose this functionality too (sans the
_) as it directly relates to the internal module system and it's useful and there is no harm generally in doing it.That said, we should also investigate what exposing it publicly would mean. What happens if someone overrides it with their own hooks? Should that change the internal reference or only further direct calls to it from outside of core?
Unlocking a module should require a very high bar.
Also - do we have any info on who else is using this from the outside?
It's not clear, why is this a problem at all. Algorithm is fixed, so implementing it in userland should be possible
It's fixed in theory. Things do actually change in it from time to time. I think @nzakas has made a pretty compelling argument that people want this behavior. It's already exposed, so I don't think committing to it is a bad idea.
Reacted by Rich TrottIt's already exposed, so I don't think committing to it is a bad idea.
That's the crux for me. It's already exposed, people are already using it. Exposing "private" methods and expecting people not to use them is something that we should try to correct where we can, and it seems that we can here.
@Trott the whole module is "private"
is something that we should try to correct where we can, and it seems that we can here.
We can't just document everything that's exposed.
@Trott the whole module is "private"
True, it's "private". It's also:
- exposed
- being used by people
- something the project is saying will not change
- the subject of a valid use case (at least for
_findPath())
Those things taken as a whole seem to suggest that documenting
_findPath()is both a low-risk and user-friendly approach.There are other considerations, of course, and this may not be the right path after all. I don't see that as a foregone conclusion.
exposed
A lot of things are exposed.
being used by people
People use everything they can find
something the project is saying will not change
Public APIs are not going to change, and behaviour is not going to change. Stuff like
_findPathdoesn't even have well defined semantics. If we just take a random internal function, make it public and commit to never change it, we might found ourselves in trouble later.13 remaining items
- added a commit that references this issue
on Oct 26, 2017 I don't understand how #16397 resolves (no pun intended) this issue. I've tried doing
require.resolve.paths(process.cwd())but it doesn't return what I expected. I expected it to return more or less whatModule._nodeModulePaths()does. I've made a small repo to better illustrate my confusion.Thanks! Just built your PR and the
pathsoption torequire.resolvenow works as I expected 🎉I still don't understand the use case for
require.resolve.pathsas implemented but that's fine since I don't actually need it.I still don't understand the use case for require.resolve.paths as implemented but that's fine since I don't actually need it.
Assume you called
require.resolve().require.resolve.pathsprovides a list of all of the directories that would have been searched by thatresolve()call.Reacted by Tamlyn Rhodes and Furkan Tunalı- added a commit that references this issue
on Dec 7, 2017 - added a commit that references this issue
on Dec 12, 2017 - added a commit that references this issue
on Jan 27, 2018
tl;dr I'd like to propose an additional API be exposed to Node.js JavaScript that allows developers to perform
require.resolve(), but with an custom list of lookup paths.Background
In ESLint, we allow people to extend their configuration files with Node.js packages, so you can do something like this:
And then ESLint
requireseslint-config-airbnb. That worked fine until people started creating shareable configs, published on npm, that wanted to inherit from other shareable configs (also published on npm). In that case, they'd want therequirelookup to happen from their config file and not from the ESLint file doing therequire.Our Solution
What we ended up doing to get this to work: https://github.com/eslint/eslint/blob/master/lib/util/module-resolver.js
In short:
Module.globalPathsandmodule.pathsModule._findPath()to do the lookup, passing the lookup paths arrayThe obvious ugliness here is that we're not just relying on
Module, but we're relying onModule._findPath(), which seems to indicate that this method should not be used (assuming the underscore is intended to mean "private".What I'd Like
Some way to get the functionality of
Module._findPath()that is an official Node.js API that we can rely on without fear of it changing or being removed. Some possible options (definitely not exhaustive):require.resolve()that allows you to pass an array of lookup paths.Module._findPath()by creating something likeModule.resolveFromPaths()that callsModule._findPath()under the coversOf course, these are just a few ideas I had in my head. Anything that accomplishes the same functionality would be awesome.
Prior Art
It seems like there's a larger need for this capability based on modules available on npm:
resolve.require.resolveusing CWD as the root. 50,000 downloads in the past month.require.resolvefrom any arbitrary path. 1.5 million downloads in the past month.