You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Exposing the logic behind require.resolve() via a public API #16389
Node.js does not expose any public API for resolving dependencies. As a result, there are many packages in the ecosystem that are trying to reimplement/mimic Node's module resolution algorithm.
The big problem with these implementations is that they don't work the way Node's require.resolve works. For instance, both resolve and resolve-from were preserving symlinks by default. I did PRs to both packages to fix this issue but they are just a drop in the ocean.
I work on pnpm - a Node package manager that uses a symlinked node_modules structure. This node_modules structure is Node.js-compatible (when Node is executed w/o the --preserve-symlinks flag) but because of the many incorrect implementations of Node's module resolution algorithm, pnpm is basically unusable with most of the popular frameworks/toolings.
Exposing Node's resolution algorithm would allow experimenting with different node_modules structures and tools/frameworks would adjust because they would resolve dependencies correctly.
Seems like the PR by @cjihrig would make it possible to replace the resolve-from by @sindresorhus. However, resolve works asynchronously. Could an async implementation be added to Node as well? I am afraid some tools might prefer to stay with an async implementation.
If the async implementation is too much in node core, maybe it can be in an official module maintained by Node that would work 100% the way sync require.resolve works.
I am personally fine with the sync require.resolve. What I mean is that there are implementations of require.resolve in userland which are async (like substack's resolve).
So I wonder if it would be enough to have only a sync require.resolve exposed or some packages would still prefer an async one from userland.
Activity
cjihrig commentedon Oct 22, 2017
Related: #5963
zkochan commentedon Oct 23, 2017
Seems like the PR by @cjihrig would make it possible to replace the
resolve-fromby @sindresorhus. However,resolveworks asynchronously. Could an async implementation be added to Node as well? I am afraid some tools might prefer to stay with an async implementation.If the async implementation is too much in node core, maybe it can be in an official module maintained by Node that would work 100% the way sync
require.resolveworks.cc @ljharb
P.S. thanks for the quick response!
bnoordhuis commentedon Oct 23, 2017
require.resolve()? It's synchronous.If "resolve works synchronously" is what you intended to write, just wrap it in
process.nextTick()orsetImmediate().zkochan commentedon Oct 23, 2017
I am personally fine with the sync
require.resolve. What I mean is that there are implementations ofrequire.resolvein userland which are async (like substack's resolve).So I wonder if it would be enough to have only a sync
require.resolveexposed or some packages would still prefer an async one from userland.module: support custom paths to require.resolve()
module: support custom paths to require.resolve()
module: support custom paths to require.resolve()
module: support custom paths to require.resolve()
module: support custom paths to require.resolve()
module: support custom paths to require.resolve()