Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esm: Make import.meta.resolve(…) take an options argument #31861

Closed
ExE-Boss opened this issue Feb 19, 2020 · 2 comments
Closed

esm: Make import.meta.resolve(…) take an options argument #31861

ExE-Boss opened this issue Feb 19, 2020 · 2 comments
Labels
esm Issues and PRs related to the ECMAScript Modules implementation.

Comments

@ExE-Boss
Copy link
Contributor

require.resolve(…) takes a second optional options argument, instead of a second optional parent string argument.

This differs from what's been implemented in #31032.

import.meta.resolve(…) and require.resolve(…) should both take a string and an options object, instead of one taking two strings and the other taking a string and an options object.


/cc @guybedford

@MylesBorins
Copy link
Member

@ExE-Boss the intent of the api is to make something that could also be implemented / standardized for browser use cases... so it is not using require.resolve as a reference API.

There is a discussion in the import maps proposal related to this. WICG/import-maps#79

FWIW I'm not saying that we should or should not have an options argument, more pointing towards motivation for the existing API. Part of the reason it is behind a flag is to give us time to workshop and create something that can be cross platform

@targos targos added the esm Issues and PRs related to the ECMAScript Modules implementation. label Dec 27, 2020
@GeoffreyBooth
Copy link
Member

Per #43363 we’re matching the browser standard at whatwg/html#5572.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation.
Projects
None yet
Development

No branches or pull requests

4 participants