Skip to content

Expose file resolution as a utility #51855

@ef4

Description

@ef4

What is the problem this feature will solve?

Tool authors often need to reimplement Node's resolving behaviors in order to ask the question: if this file was to import this path, which file would Node resolve that to?

This comes up for build tools like Vite, Esbuild, or Webpack. It also comes up for analysis tools like Eslint and Typescript.

For a long time, people were able to get by with the likes of https://www.npmjs.com/package/resolve. But the introduction of the full suite of package.json exports features (conditions, subpath imports, etc) and ESM have resulted in a situation where almost no tool actually covers Node's complete spec correctly anymore. It seems wasteful to try to fix all these parallel implementations rather than share node's implementation as a utility.

What is the feature you are proposing to solve the problem?

A node-provided, importable constructor that takes conditions:

import { Resolver } from 'node:resolver';
let r = new Resolver({ 
  conditions: ['default', 'node', 'development' ]
});

Where the Resolver instance offers a method with the signature:

resolve(requestedPath: string, requestingFile: string): Promise<string | undefined>;

The key features provided here that are not provided (AFAIK) by any existing Node API are:

  • you can programmatically ask what would happen under the given conditions. These are distinct from the global --conditions that prevail in the current node process (remember -- we're talking about running this inside a tool like a linter. Regardless of what conditions the linter uses for its own implementation, it should follow imports the way the user's program is going to do it, using the user's conditions.)
  • you can ask on behalf of another file in another package. Critically, this would need to respect rules like self-referencing. This is in contrast with require.resolve which, even if you set paths to the inside a package doesn't respect the self-referencing rule.

Note that I'm definitely not asking for access to the state of the current node process's resolver. I don't want its customized loaders, I don't want to share its cache. Rather, this would be asking to set up an entirely separate state that would not interfere with Node's own module loading at all.

What alternatives have you considered?

There are lots of third-party implementations, maintained at great effort and all with incomplete support for Node's behaviors. In theory somebody could invest the effort to make one of them perfect and continually invest in making it follow new node features.

Metadata

Metadata

Assignees

No one assigned

    Labels

    esmIssues and PRs related to the ECMAScript Modules implementation.feature requestIssues that request new features to be added to Node.js.loadersIssues and PRs related to ES module loadersloaders-agendaIssues and PRs to discuss during the meetings of the Loaders teamnever-staleMark issue so that it is never considered stale

    Type

    No type

    Projects

    Status

    Awaiting Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions