Implement <script type=module>

[justinfagnani]

<script type=module> is supported across all major browsers now, but not in jsdom yet. This can be a tracking issue for the feature.

Node.js doesn't support modules without flags either, and it's unclear exactly how much Node support will be compatible with the web. It's possible to implement support without native support in Node, possibly using projects like https://github.com/standard-things/esm Care would have to be taken to match web behavior and capabilities.

[ExE-Boss]

Also, it will be necessary to add support for <script nomodule> at the same time as support for <script type="module">, so that the issue with Safari 10 shipping modules without <script nomodule> doesn’t occur a second time, this time with JSDOM.

[Heydon]

Here to register my support for implementing type="module" and nomodule. As @justinfagnani rightly points out, it is supported across almost all modern browsers (and is doubtless not going anywhere.)

[RangerMauve]

There's a bunch of breaking changes coming to the ESM support in the VM modules so it might be a good idea to support nomodule first, and add type="module" after Node has stabilized a bit.

[domenic]

To be clear, we won't be landing patches for this until Node.js has a stable API for JS modules in the vm module, which would allow us to emulate the spec semantics. In the meantime, +1s or comparisons with browsers are not very helpful, as we simply can't implement this. (At least, not in a way that is compatible with jsdom's standards-compliant architecture, instead of being a nonstandard shim on top of jsdom like the esm package.)

[Heydon]

@domenic Sure, I'm just all for it being implemented when possible. Thanks for the info.

[justinfagnani]

Why would using esm be a non-standard shim? If the result is spec compliant, and there's no user-visible difference from a Node-native implementation, what would be the issue?

[domenic]

The result is not spec-compliant.

[ExE-Boss]

@justinfagnani The result of using esm is not spec‑compliant because esm transpiles ES6 modules into CommonJS modules at runtime.

[justinfagnani]

In what way? You can turn off CJS import support, and I would presume any integration would use mime types in a spec compliant way.

[domenic]

For example, it doesn't allow the support we'd need to implement the module map (including populating it via module preload, ensuring the correct base URL is set for import.meta.url, etc.), credentials modes, fetch modes (CORS required), referrer policy, setting document.currentScript to null, separation of parsing, instantiation, and evaluation phases, ...

In other words, let me know how many tests from https://github.com/web-platform-tests/wpt/tree/master/html/semantics/scripting-1/the-script-element/module esm passes.

[justinfagnani]

Thanks for the details. I definitely assumed that any implementation, whether it used something like esm or not, would have to be JS and HTML spec compliant. I don't think using a user-land solution precludes that.

@ExE-Boss esm performs its own script wrapping. I don't think it's accurate to say that it compiles to CJS.