ECMAScript 2016+ in Firefox

Post by pjmlp » Thu, Feb 23, 2017, 6:24 AM UTC

emn13 wrote: post #76

hzoo wrote: post #34

Earlier quoted context omitted.

Yep and with Babel we recommend using https://github.com/babel/babel-preset-env to compile only what's missing in the targets you support. Hopefully we have a better solution about making multiple bundles (separate one for IE) soon

I'm currently experimenting with if-no-window.Promise-then-polyfill via polyfill.io (I dont quite trust synchronous dynamic script loading yet, but we'll see if that's robust enough on old browsers). Sure, old browsers need an extra roundtrip, and it's an additional point of failure - but it simplifies dev tooling, and if your users actually cared about perf, they wouldn't be using ancient browsers. It won't fix many…

Post by allover » Thu, Feb 23, 2017, 9:22 AM UTC

z3t4 wrote: post #70

allover wrote: post #68

Earlier quoted context omitted.

ES6 modules are great because they're statically analysable, whilst CommonJS modules aren't.

just parse it like any other js code

Post by z3t4 » Thu, Feb 23, 2017, 1:09 PM UTC

nailer wrote: post #84

allover wrote: post #83

Earlier quoted context omitted.

By that do you mean you can 'just parse' CommonJS modules? (If so) CommonJS allows you to dynamically alter module.exports anywhere within your module. You can't determine what those exports are just by parsing, you'd need to execute the code.

> CommonJS allows you to dynamically alter module.exports anywhere within your module It's certainly a risk, but that isn't a common practice.

  if(Math.round(Math.random()) === 1) {
    export let foo = bar; // have fun debugging!
  }

Post by allover » Thu, Feb 23, 2017, 6:25 PM UTC

z3t4 wrote: post #85

nailer wrote: post #84

Earlier quoted context omitted.

> CommonJS allows you to dynamically alter module.exports anywhere within your module It's certainly a risk, but that isn't a common practice.

There's also ... if(Math.round(Math.random()) === 1) { export let foo = bar; // have fun debugging! } I think it would also be fine to execute modules to see what's in module.exports, while some modules might have side effects like writing to /etc/passwd without calling any method, it's not the norm.

Post by z3t4 » Thu, Feb 23, 2017, 7:36 PM UTC

allover wrote: post #87

z3t4 wrote: post #85

Earlier quoted context omitted.

There's also ... if(Math.round(Math.random()) === 1) { export let foo = bar; // have fun debugging! } I think it would also be fine to execute modules to see what's in module.exports, while some modules might have side effects like writing to /etc/passwd without calling any method, it's not the norm.

> There's also ... [...] (I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level). Doesn't your example highlight exactly why even executing the code wouldn't even help you there?