-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exposing the logic behind require.resolve()
via a public API
#16389
Comments
Related: #5963 |
Seems like the PR by @cjihrig would make it possible to replace the 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 cc @ljharb P.S. thanks for the quick response! |
If "resolve works synchronously" is what you intended to write, just wrap it in |
I am personally fine with the sync So I wonder if it would be enough to have only a sync |
This commit allows custom lookup paths to be passed to require.resolve(). It also adds require.resolve.paths() which retrieves the default resolution paths. Fixes: nodejs/node#5963 Fixes: nodejs/node#16389 PR-URL: nodejs/node#16397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This commit allows custom lookup paths to be passed to require.resolve(). It also adds require.resolve.paths() which retrieves the default resolution paths. Fixes: #5963 Fixes: #16389 PR-URL: #16397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This commit allows custom lookup paths to be passed to require.resolve(). It also adds require.resolve.paths() which retrieves the default resolution paths. Fixes: #5963 Fixes: #16389 PR-URL: #16397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This commit allows custom lookup paths to be passed to require.resolve(). It also adds require.resolve.paths() which retrieves the default resolution paths. Fixes: #5963 Fixes: #16389 PR-URL: #16397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This commit allows custom lookup paths to be passed to require.resolve(). It also adds require.resolve.paths() which retrieves the default resolution paths. Fixes: nodejs/node#5963 Fixes: nodejs/node#16389 PR-URL: nodejs/node#16397 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
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.
resolve, resolve-from, eslint-plugin-import... just to list some of them.
The big problem with these implementations is that they don't work the way Node's
require.resolve
works. For instance, bothresolve
andresolve-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.
The text was updated successfully, but these errors were encountered: