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

How should we deal with module attributes? #92

Open
JLHwung opened this issue May 18, 2020 · 1 comment
Open

How should we deal with module attributes? #92

JLHwung opened this issue May 18, 2020 · 1 comment

Comments

@JLHwung
Copy link

JLHwung commented May 18, 2020

Babel 7.10 is going to support parsing stage-1 module attributes

await import("./package.json", { with: { type: "json" } })

Currently this plugin will transform the code above to

await Promise.resolve().then(() => _interopRequireWildcard(require("./package.json")));

where module attributes are excluded.

Given that node require supports JSON, I think the current situation is still acceptable, but only if type: "json" is the only accepted in the proposal. That said, if the spec will allow other type values in the future, we should decide

Should we skip the import node with module attributes? Since we can offer a custom plugin to transform module attributes into bundler-specific annotations, e.g. import(/* webpackChunkName: "lodash" */ 'lodash')

Or should we still treat them as those without attributes? A warning message can be printed since it may not be natively supported on node.js, but users may intend to pass the transpiled sources through bundlers which may support them via file extensions.

I don't have preference between these two solutions, or maybe we should even pursuit for an option. Other solutions are definitely welcome.

@ljharb
Copy link
Collaborator

ljharb commented May 18, 2020

It doesn’t matter what other type values there are - the proposal already supports any string you want; it’s up to the engine to decide what it supports. In other words, until node itself makes a decision on what to support, there’s no right answer here. I think the current behavior makes the most sense - ie, ignoring attributes entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants