Tools: Edge supports ES6, but not object spread operator

Created on 19 Apr 2018  Â·  5Comments  Â·  Source: Polymer/tools

Currently we have the js.compile option which is either true (es5 output) or false (es6 output). While Edge supports es6, it does not support newer syntax such as object spread. We either need to add more granular JS build settings or update browser capabilities for Edge.

Most helpful comment

I think for these cases supporting babel-preset-env is the best. We have
had so many GitHub on this single thing (e.g. Babel compilation with
different targets) that this solution seems necessary.

On Thu, 19 Apr 2018, 06:30 Alexander Marks, notifications@github.com
wrote:

cc @frankiefu https://github.com/frankiefu

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/tools/issues/173#issuecomment-382607114, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFrDb4sAVV01C80osjEZgXcIyFqPCk6Hks5tqBLigaJpZM4Ta70n
.

All 5 comments

Currently, js.compile = false means "do not compile". It does not mean produce es6. Neither async/await nor object-rest-spread are part of es6, they are part of es2017 and es2018 respectively. There's also the exponentiation operator in es2016.

Proposal:

  • Add an es6 option (or maybe es2015 since that's what we call it in browser-capabilities) to compile, which will transpile to es6 (meaning just async/await, object-rest-spread, exponentiation, and whatever lands in Babel from es2018 onwards down the road).

  • We can either leave false as-is (no compilation), or interpret it as an alias for es6. If we did that, as time goes on, we would presumably want to bump the meaning of false to capture the "minimally compiled for the main evergreen browsers" setting. We could also deprecate true|false altogether, and add an explicit none value so that this is not ambiguous.

The other thing to consider here is moving to babel-preset-env. If we integrated this, you would configure very specific browser requirements (e.g."last 2 versions, ie 10") and we would then transpile to a build with the lowest common denominator of features needed for those browsers. Probably not something I would want to do in the next few weeks timeframe, though.

cc @frankiefu

I think for these cases supporting babel-preset-env is the best. We have
had so many GitHub on this single thing (e.g. Babel compilation with
different targets) that this solution seems necessary.

On Thu, 19 Apr 2018, 06:30 Alexander Marks, notifications@github.com
wrote:

cc @frankiefu https://github.com/frankiefu

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/tools/issues/173#issuecomment-382607114, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFrDb4sAVV01C80osjEZgXcIyFqPCk6Hks5tqBLigaJpZM4Ta70n
.

Adding js.compile = 'es2015' (to align with brower-capabilities) SGTM, with js.compile = true being the same as today (optionally add 'es5' alias for the same thing). I think js.compile = false (or undefined) should remain as "do nothing" so its meaning doesn't constantly update.

babel-preset-env would be nice to have in the future, but probably too much for now.

For reference, desktop Safari 11.0.3 (previous stable version) also doesn't support object spread. Like Edge, it will getting the es6-bundled build (not esm-bundled since it doesn't have import.meta), so that build should definitely have object spread transformed.

Was this page helpful?
0 / 5 - 0 ratings