Support import.meta.resolve baseURL argument

[guybedford]

This specifies a new optional second argument for import.meta.resolve which supports a custom baseURL to be provided.

This effectively generalizes import.meta.resolve to act as a global resolver which can be useful for performing arbitrary module resolutions.

Node.js already implements this feature, and Deno has expressed implementation interest.

• At least two implementers are interested (and none opposed):
  • Node.js
  • Deno
• Tests are written and can be reviewed and commented upon at:
  • import.meta.resolve second baseURL argument web-platform-tests/wpt#34692
• Implementation bugs are filed:
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): Already implemented
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): import.meta.resolve second argument denoland/deno#15073
  • Chrome: Will file pending review
  • Firefox: Will file pending review
  • Safari: Will file pending review

(See WHATWG Working Mode: Changes for more details.)

---

/webappapis.html ( diff )

[domenic]

So two issues with this:

• I don't think a global resolver belongs on import.meta, because it's no longer specific to the current module like all existing import.meta properties are. Instead you just seem to be using it as a sort of weird global namespace. Something like self.resolveModuleSpecifier() or HTMLScriptElement.resolve() would make more sense to me.

• Even if we put that aside, it seems unlikely that we want to lock in all future uses of the second argument this way. I suspect there may be other (perhaps more appropriate) modifiers we apply to resolution in the future, so an options bag seems more reasonable here, e.g. import.meta.resolve(x, { baseURL }).

Apart from these specific issues, I'd encourage you to open an issue with a proposal, instead of jumping to a spec and tests PR and asking for review time from people. Such a proposal could include things like justifications why this is important, use cases, examples, etc.

[guybedford]

Thanks for the feedback, very good point with regards to the options bag second argument possibly being a more future-extensible design. I've posted #8077 for further discussion on the topic.