Support ESM resolution

Hiya! 👋

We’ve discussed this briefly on Slack, but I thought an issue would be easier to keep track of.

I’m not sure what it would entail, so I’ll just list out (i.e. do a brain dump of) the features I think would be needed.

• Should file be interpreted as CJS or ESM
  • Currently, resolve will only ever return a single string, which is the absolute path to the resolved file. I think in addition to this, we’d need to know if the file should be interpreted as CJS or ESM
  • Related, should resolve taken an option what the caller would prefer? Should it be a static option in, or some callback?
• Support exports field in package.json
  • Docs: https://nodejs.org/api/esm.html#esm_packages
  • Again, should the caller be able to define which they want? EDIT: Ish, via conditions
• Support promise for async resolution
  • This is admittedly not a requirement, but it matches the Node APIs making it cleaner to use resolve when implementing custom loaders or using the VM APIs.
  • #210
• Support URLs. Mostly because import() supports it. It probably makes more sense for resolve to return URLs than an absolute path for ESM?
• Preserve query strings
  • Makes sense, but just adding it here as a point

There is also a flagged API in Node for this, import.meta.resolve: https://github.com/nodejs/node/pull/31032. Not sure if we should care too much about it, though?

I think that covers it, but you know way more about this subject than I do, so feel free to either close this to open up your own, or edit this OP as you see fit 👍

---

For background, Jest uses resolve as the default implementation in jest-resolve, although the user can swap it out. I’m currently working on support for ESM natively in Jest, and while we have a version today that sorta works, it’s not a compliant implementation. Most of the (known) issues are due to resolution logic. I’d be happy to help implement support here in resolve.

[ljharb]

@IanVS yes, it’s something i very much want to complete. I’ll try to prioritize it this month.

[overlookmotel]

That said… it seems like a pretty niche case. So if it were practical to provide a sync version (with an explicit warning that it does not support async resolution like https import), it could still be useful in the majority of cases.

I am using enhanced-resolve (Webpack’s implementation) for now, which does provide sync resolution. But my understanding is that everyone will switch to resolve library once ESM support is added, and other implementations will likely fall into disrepair. So just wanted to flag sync resolution is useful for at least some users.

I’ll stop banging on about this now!