You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some (most?) servers don't know what .mjs is which causes servers to serve the wrong mime type (octet stream?) which causes browsers to not execute the module.
I think in Node, they're moving towards pkg.module (from .mjs and pkg.jsnext:main) which means .mjs won't be getting a good mimetype anytime soon. And server-side configuration is annoying, especially if you don't have access/can't configure/don't know how to do it/just can't do it.
Also, the regular build could be *.umd.js for consistency.
I could be wrong. Thoughts?
Versions affected:
All builds that emit .mjs.
Platforms affected:
Chrome (60? The one that supports ES modules). Have not tested Safari (I'm rarely on a Mac when playing around).
Reproduction:
Install the Chrome version that supports ES modules.
Install lite-server (I think http-server also works just as fine).
Create two JS modules, one importing the other. You can just add a console.log() on both.
Create an HTML with <script type="module" src="path/to/script/that/loads/the/other.js">.
Run the static server to serve that HTML.
Browser loads both scripts, but won't parse the second one (and possibly its dependencies), causing the entire tree to just halt. Chrome silently fails when this happens, not even a parse error.
The text was updated successfully, but these errors were encountered:
I think it wouldn't hurt to throw out a ractive.es.js that is also not transpiled and leave the .mjs as transpiled. This all gets a bit confusing with node starting to use .mjs and various bundlers using the pkg:module or pkg:jsnext:main. You can legitimately want a transpiled es module for use with IE via webpack, but want to use modules in browser where transpilation only adds fluff to the code.
Is anyone clear on exactly what/when/why node will load an mjs over a js? Once that's settled, we can decide whether to point the pkg:module at the transpiled version that is appropriate.
Haven't been in the JS scene for a while, not sure where it's headed. But I read Node is really going for .mjs. I think it won't be long before servers and tooling serve .mjs as JavaScript in line with Node using .mjs for ES modules. This was just a stopgap solution to have existing servers use the correct mimetype without fiddling with the server.
Description:
Some (most?) servers don't know what
.mjs
is which causes servers to serve the wrong mime type (octet stream?) which causes browsers to not execute the module.I think in Node, they're moving towards
pkg.module
(from.mjs
andpkg.jsnext:main
) which means.mjs
won't be getting a good mimetype anytime soon. And server-side configuration is annoying, especially if you don't have access/can't configure/don't know how to do it/just can't do it.Also, the regular build could be
*.umd.js
for consistency.I could be wrong. Thoughts?
Versions affected:
All builds that emit
.mjs
.Platforms affected:
Chrome (60? The one that supports ES modules). Have not tested Safari (I'm rarely on a Mac when playing around).
Reproduction:
lite-server
(I thinkhttp-server
also works just as fine).console.log()
on both.<script type="module" src="path/to/script/that/loads/the/other.js">
.Browser loads both scripts, but won't parse the second one (and possibly its dependencies), causing the entire tree to just halt. Chrome silently fails when this happens, not even a parse error.
The text was updated successfully, but these errors were encountered: