Publish `exports` and `imports` implementations as separate module(s)

What is the problem this feature will solve?

Projects implementing support for module resolution have to add support for the quite advanced exports and imports fields in package.json.

https://nodejs.org/api/packages.html#exports
https://nodejs.org/api/packages.html#imports

Examples of projects that have done this are Webpack, TypeScript, Jest (only exports, not imports), Yarn and probably more. AFAIK neither Rollup, Parcel or Metro (to name some bundlers) have support.

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

If the algorithm Node uses internally was published as a separate module, I hope (and believe) more projects would be able to add support more readily, and that ecosystem compatibility would improve as a result.

I think part of the reason is the complexity in supporting the algorithm needed, particularly with subpath exports, wildcards and conditionals. E.g. https://github.com/browserify/resolve/issues/222 is stuck, and https://github.com/facebook/jest/issues/9771 took a long time.

Prior art for externalizing parts of Node publishing cjs-module-lexer separately, which means Jest could implement the same feature as node itself when importing CJS from ESM (via vm API).

Note that this is not a request for the full require or ESM resolution algorithm. This is solely a request for "given this exports/imports, this specifier and these conditions, what path does it map to" - no FS access/lookups at all. API similar to https://github.com/lukeed/resolve.exports makes sense to me.

What alternatives have you considered?

Jest (and Yarn) currently use https://github.com/lukeed/resolve.exports to avoid having to implement all the resolution. It currently does not support imports (https://github.com/lukeed/resolve.exports/issues/14).

先从链接的 Node.js package exports 和 imports 文档开始，然后对照所引用的 resolve.exports 模块及相关示例。确定一个无需访问文件系统、用于映射 specifier 和 conditions 的独立实现的范围；完成的标准是，所提议的模块覆盖 exports 和 imports，同时仍与完整的 require 或 ESM 解析保持分离。