Microbundle: Output ES modules bundles

Created on 21 Jul 2018 · 17Comments · Source: developit/microbundle

Apart for all the amazing automated work and the bundles generated, we should output ES modules bundles with the help of babel-preset-env

{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "esmodules": true
      }
    }]
  ]
}

This will help devs ship less javascript if they support shipping these bundles by any possible way.

enhancement help wanted

Source

prateekbh

Most helpful comment

Whats the status on this?

porfirioribeiro on 1 May 2019

👍3

All 17 comments

We do not support babel yet (we use buble).

Main focus of this package is to help people build & package front-end libraries, which means we can't support esmodules bundles right now because there is no spec on how people should consume them automatically. What I mean is that "main"/"module" entries should contain valid es5 for backwards compatibility, older browsers support etc. If somebody want to support newer environments bundlers should know how to chose some other field from package.json over "main"/"module" if bundling for newer targets. This is tricky though because people would like to support even newer environments than those specified by esmodules, and it seems that we shouldnt just publish dozens of files to npm, but rather compile to like the newest standard and support transpiling node_modules with bundlers so every consumer can just chose what they want to support, but as "newest standard" is a moving target (over time) this whole thing is tricky.

Andarist on 22 Jul 2018

Compiling for esmodules is a strong signals that these can be used with <script type=module. Always shipping with latest standard would mean that the end user keeps to updating there compilation plugins to understand ES2017/18... and so on.

But anyways here's a proposal format that angular follows I guess.
https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/preview#heading=h.k0mh3o8u5hx

And even if we don't want to support this package at least we should build a bundle consumable by <script type=module and leave for the user to put it in library package.json or not.

If this sounds experimental then let's a flag to build this bundle but at least have some way of bundling it.

The browsers are ready to consume scripts less transpiled, and I see no reason why we should only supply ES5 to everyone

prateekbh on 22 Jul 2018

I'm not against shipping a bundled ES201x bundle in addition to the current ones, though it would be really nice if there was a way to point to it from a package.json (the module field being already overloaded).