Failure is upstream, I've opened an issue on babel-plugin-transform-async-to-promises to report the dead Promise.resolve().

@developit Give 0.8.12 a go

@JoviDeCroock – The issue is defining "modern."

The module/nomodule pattern provides the only declarative html driven approach to segmenting functionality. By default module means a lower transpilation ceiling than nomodule, but it's target rapidly decays compared to the next definition of "modern."

We need better signals from user-agents.

@kristoferbaxter are you talking about some server that would sniff the user agent and return the correct index.html (with corresponding bundle)?

I'm saying that a more pure declarative signal sent via headers is important. But also, for static documents to be able to leverage via mechanisms similar to declarative html treatments for module/nomodule.

We can only work with what we have available today – so the most modern you can provide in a statically defined way is module/nomodule.

Glad to see we're sticking to the syntax.esmodules, built a small webpack plugin when this would go live. 👍 great work @developit really excited about this

Gotta rebase 👀

Update is already in master

I should have clarified in my PR description: I view target:esmodules as an initial step here, and we'll take another pass at this soon. Once the community has indicated a direction to take for defining modern (or defining syntax levels!) Microbundle will be in a position to output that.

It might be that we decide on "state your syntax and entry", in which case we'd have microbundle generate ES2018 and es5, or steps between the two.

if i don't set this flag, will preset-env respect the browserlist settings in my package.json? Because it also turns on modules (i am 99% sure) if i force modern browsers by their versions. I use edge last 1 version and ff, chrome and safari last 2 versions + mobile equivalents for ios, ff and chrome the most times.

@hbroer esmodules and browserslist can't be used in combination, since esmodules is a effectively "browser list" preset. I believe in the current setup as of this PR, your browserslist in package.json will be applied to the non-modern output, since the modern output is specifically the esmodules preset option.

FWIW it sounds like your browserslist configuration is really really close to target.esmodules, so you might be better off just rolling with the defaults here? Something like microbundle -f modern,umd would produce a modern ES Modules output and an ES5 + UMD fallback, which is sufficient for most packages+bundlers.

My understanding of the flag is that it only turns on modules, but everything which is newer than that feature is transpiled. I really have to take a look into that, because this is only what i think i know with a big question mark above my head ^^

I think this would transpiled to Object.assign() with modules flag on:

{...otherObject, x: "new value"}

And I would expect it doesn't transpile if I set browserlist to chrome and firefox last versions (and nothing else).

@hbroer your understanding is correct. I agree it would be nice to have the modern output format here use a newer syntax mode, but it's hard to make a call on what exactly that cutoff point should be. Lots of folks will want to use the modern version of libraries directly in a browser, which means it's useful to have something like module/nomodule to know when to load the modern syntax.

I think we can improve on this over time, but for now target:esmodules is a pretty safe balance.

Ok sounds fine. Maybe there should be a notice in the readme that it is possible to use browserlist instead of the flag to address browsers directly.

Yup, we can add that - it actually became possible by accident when we switched to Babel last week!