Closed fuzetsu closed 2 months ago
Could you find some relevant discussion on Preact's side?
Also, I consider this a subbug of #1886, not a strict duplicate.
@isiahmeadows
There doesn't seem to be a huge amount of discussion specifically about switching from mjs to js. but quite a bit around the issues pre switching. My impression is that getting rid of the module bundle was not an option for them, and changing the extension was an acceptable workaround, so they just went with it when they found it. There might be some behind the scenes discussion I'm not finding.
Here are few comments/isses that mention the switch: https://github.com/preactjs/preact/issues/1424#issuecomment-474527235 https://github.com/preactjs/preact/issues/1321 https://github.com/preactjs/preact/pull/1425 https://github.com/preactjs/preact-render-to-string/issues/86#issuecomment-485958898
I also checked their slack, but wasn't able to find many references to this topic there.
Okay, it appears they've been pointing people to this Webpack plugin as a workaround, and we apparently weren't the only ones running into inconsistent module resolution logic with Webpack. (We may have just ran into a different variant of the same greater problem.)
I'm open to this, and feel free to send a PR. Here's generally what I'm thinking:
mithril/index.module.js
would work like mithril/index.js
, but 1. export everything as named exports, including mithril/render/hyperscript.js
as m
and 2. not attach everything to a hyperscript proxy to re-export as default. (We want to push people to use the named exports where applicable, to maybe save some bundle size.)export * from "./render.js"
for mithril/render.module.js
and similar. I don't want these to be magic, and I'd rather not duplicate implementation. We can just continue to instruct Rollup users to install rollup-plugin-commonjs
, since many Mithril libraries already require this. In the future, this might change if/when we migrate the core code base to ES6, but it's just kicking the can down the road.Sound good! :+1: I'll try to submit a PR this week, hopefully tomorrow.
Make sure to include a "module:" property in package.json so that unpkg, pika and other CDNs can serve the module easily.
Closing due to age.
Description
In mithril 2.0.0-rc.5 the ESM bundle was removed (#2366). This was done mainly because of issues with webpack that caused confusion among users. Webpack would use the
mjs
file instead of thejs
file and not expose the default export in the standard way.preact had a similar issue because they also provided an
mjs
version of their bundle on npm. In their 10.0 beta they resolved this issue by changing the file extension tomodule.js
which does not cause issues with webpack.Why
Considering that most competing frameworks/libraries offer such a bundle, new users are likely to expect it, and even though using a script tag continues to work fine it's nice to have the option to use native modules when writing an app without a build process.
Other frameworks' bundle:
Possible Implementation & Open Questions
This is the commit that fixed the issue for preact. I propose we follow suit, and just change the extension to
module.js
.https://github.com/preactjs/preact/commit/8ea29b5e92d69ddc4279833b19cb50294a91b923
Do we want to continue to use our custom scripts to generate the esm build? Are we ready for rollup or something similar? (maybe too much change at this point) #1886
Is this something you're interested in working on?
Yes