See https://www.pika.dev/search?q=alpine and https://github.com/rollup/rollup/wiki/pkg.module for an explanation.
Essentially, now that JavaScript modules are defined and there are adaptors to use them anywhere, there’s no good reason to distribute a CommonJS library anymore besides a legacy build tool chain, but Alpine is a new project and shouldn’t have that problem.
@carlmjohnson I've submitted a PR that adds ESM output
Unfortunately, since Alpine exports a monolithic "Alpine" object, ESM doesn't confer any special benefits vs UMD/CommonJS (usually ESM would allow for better treeshaking but a single export is not treeshakeable). Only benefit might be that with ESM output AlpineJS would be listed on Pika.
It actually ends up being a larger bundle than the UMD one.
As an aside Rollup docs recommend transpilation of everything but the ESM export/import syntax hence the similar sized bundle.
I'm not so sure about larger bundle than UMD. In theory, because ESM is natively understood by a browser it doesn't need any additional code and should be smallest imho.
In my opinion, listing AlpineJS on Pika and having a modern ESM build are two pretty important benefits ;)
@zigomir feel free to have a look in the PR at the output size of the ESM bundle https://github.com/alpinejs/alpine/pull/211 I might be missing something.
Relevant output from the build in GitHub Action
Destination: dist/alpine.js
Bundle Size: 24.8 KB
Minified Size: 16.65 KB
Gzipped Size: 5.47 KB
Destination: dist/alpine-es.js
Bundle Size: 24.58 KB
Minified Size: 17.55 KB
Gzipped Size: 5.57 KB
1K is not a big difference. Probably it just comes down to export default being a little longer when minified or something.
Yeah I think it's because you can't minify it
@calebporzio's call now though
@HugoDF thanks, I stand corrected! I see only minified is smaller – makes sense yeah :)
Sorry, I'd love for someone to spell out exactly what the benefits are of including an ESM build. Like maybe show me some code examples that do not work (at least ideally) in Alpine's current state?
@calebporzio browser script with type "module" would not be able to import Alpine as follows:
<script type="module">
import Alpine from 'https://cdn.jsdelivr.net/gh/alpinejs/[email protected]/dist/alpine.js';
Alpine.start()
</script>
Although import CDN_URL does work and will set window.Alpine.
@calebporzio browser script with type "module" would not be able to import Alpine as follows:
<script type="module"> import Alpine from 'https://cdn.jsdelivr.net/gh/alpinejs/[email protected]/dist/alpine.js'; Alpine.start() </script>Although
import CDN_URLdoes work and will set window.Alpine.Codepen: codepen.io/hugodf/pen/gOpxqzX
This code would be redundant anyway? Alpine automatically starts for you...
I'm aware
I think the case is more that you're defining everything else as a module anyway, so you don't want Alpine to be the weirdo.
@ryangjchandler have any of your recent experiments with ESM given you any more reasons an ESM build would be useful? Beyond "we can list it on Pika" and "it's a good idea to future proof the build output"
@ryangjchandler have any of your recent experiments with ESM given you any more reasons an ESM build would be useful? Beyond "we can list it on Pika" and "it's a good idea to future proof the build output"
To be honest, I'm just importing the full bundle, not the Alpine module so it's not going to make much of a difference in v2.
I think this will be a necessity for v3 though with plans to implement Alpine.method().
It would make it easier to use Alpine with Snowpack.
It would make it easier to use Alpine with Snowpack.
Does this mean it can get pulled down as a "web module" that would be neat, does it not work with regular UMD?
It would make it easier to use Alpine with Snowpack.
Interesting, I didn't know it had to me an ES module to work with Snowpack.
It will work with Snowpack, but it wraps everything in an unnecessary Common JS wrapper:
var commonjsGlobal = typeof globalThis !== 'undefined' ? globalThis : typeof window !== 'undefined' ? window : typeof global !== 'undefined' ? global : typeof self !== 'undefined' ? self : {};
function createCommonjsModule(fn, module) {
return module = { exports: {} }, fn(module, module.exports), module.exports;
}
var alpine = createCommonjsModule(function (module, exports) {
(function (global, factory) {
module.exports = factory() ;
}(commonjsGlobal, (function () {
// ... Normal Alpine code
})));
});
export default alpine;
Hi guys, I'm going to close this issue for now. I'd like to see an ESM version of Alpine available for v3, but previous attempts for v2 have been closed.
Most helpful comment
@carlmjohnson I've submitted a PR that adds ESM output
Unfortunately, since Alpine exports a monolithic "Alpine" object, ESM doesn't confer any special benefits vs UMD/CommonJS (usually ESM would allow for better treeshaking but a single export is not treeshakeable). Only benefit might be that with ESM output AlpineJS would be listed on Pika.
It actually ends up being a larger bundle than the UMD one.
As an aside Rollup docs recommend transpilation of everything but the ESM export/import syntax hence the similar sized bundle.