-
Notifications
You must be signed in to change notification settings - Fork 375
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
JSON and CSS modules dynamic import #835
Comments
This is totally reasonable and expected from my perspective. I don't think there's any other possible semantics for combining the JS module system and its default export concept. |
I agree with the above, this is expected given the semantics of modules. You also can't do |
Agreed with @domenic and @matthewp as well as this:
For CSS modules a single default export is potentially only a starting point. I have a follow-on proposal to allow for exports from a CSS module: w3c/csswg-drafts#3714 For that we would need dynamic import to work as it does with JS modules. |
Thanks all -- I'll consider the issue closed as there seems to be a pretty clear agreement on the direction here. |
The initial expectation of the test case was indeed just a mistake on my side. Thanks for following up! |
When preparing the initial implementation of JSON modules in Blink, we noticed a potentially interesting issue with dynamic import.
The original JSON module WPT test for dynamic import expected this behavior:
However, given the existing behavior of Synthetic Modules with dynamic import(),
result
actually ends up being the namespace object for the imported module, and the importer needs to check thedefault
property to get the actual value:One can argue that this was just a bug in the initial test, and we did in fact end up changing the test as part of submitting the Blink code change.
It doesn't quite seem ideal ideal to make the importer dig into the namespace object's
default
property, but it is consistent with the existing semantics for default exports. I'm not sure whether it's a serious enough problem to consider changing the semantics of how these work. A solution would either require reimplementing JSON modules without Synthetic Modules, or extending Synthetic Modules in some way, perhaps with an addition of a custom FinishModuleImport-like callback where the implementer of the Synthetic Module can customize what gets returned from animport()
of the module.All of the above applies to CSS modules in the same way, as these too are built as a Synthetic Module with a single default export of the stylesheet.
Thoughts?
cc: @littledan @Ms2ger @travisleithead @BoCupp @samsebree @domenic @justinfagnani
The text was updated successfully, but these errors were encountered: