Publish exports and imports implementations as separate module(s)

[SimenB]

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. browserify/resolve#222 is stuck, and jestjs/jest#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 (lukeed/resolve.exports#14).

[aduh95]

@GeoffreyBooth I believe you're working on exposing those APIs, correct?

AFAIK neither Rollup

FWIW Rollup already supports "exports" through their @rollup/plugin-node-resolve plugin, but I don't think it supports "imports" (there might be another plugin for that, I don't know). AFAIK they have no intention to ever add support in bare rollup, same as they don't support node_modules/ resolution without a plugin.

[GeoffreyBooth]

@GeoffreyBooth I believe you’re working on exposing those APIs, correct?

Yes, but anyone else is free to beat me to it 😄 Please just ping me on GitHub or the OpenJS Slack before you start so we can coordinate.

I’m not sure about publishing these as external packages rather than just exposing new Node APIs (like import { getPackageRoot } from 'module' or somesuch). The advantage of including them within Node is that the API would always return the result of the currently-running version of Node, whereas a project that uses an external package version might get a different result.

[SimenB]

Very happy to hear this is being worked on!

Whenever you have something running, I'd be very happy to test it out in Jest to test out the APIs in an external project. 👍

The advantage of including them within Node is that the API would always return the result of the currently-running version of Node, whereas a project that uses an external package version might get a different result.

Disadvantage is that it'll only work at all for newer versions of node, and other implementations would have to be used for older versions of node. Either way, as long as the API exists, I'm very happy 😀

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[ljharb]

it has never-stale