How to handle stage-x #14

hzoo opened this Issue Oct 7, 2016 · 4 comments


None yet

3 participants

hzoo commented Oct 7, 2016 edited

Do we want to allow for users to stage-x plugins with this preset as well?
Or should this only cover for everything under latest?

Since browsers don't implement stage-x features anyway (otherwise they'd be stage-4), it would be only supported by browsers through a flag...

Maybe we should just leave it alone and users will just specify stage-x presets individually?

  "presets": [
    ["env", {
      "targets": {
        "chrome": 52

Actually now that I think about that seems fine?

@hzoo hzoo added the discussion label Oct 7, 2016
milesj commented Oct 7, 2016

My vote is for not supporting stage-x features.

  1. They're possibly not implemented natively.
  2. If they are, they can be behind flags (like you said), which simply opens up to many configuration possibilities to support.
  3. We should focus on solidifying the accuracy of features that are supported natively.

If there's a case, or could be in the future a case, where a vendor has implemented stage-x features without any special flags needed, then the project should definitely take advantage of that.
However, I'm not that familiar with the stage system - is that a likely or even possible scenario?

hzoo commented Oct 7, 2016

Agreed, Yeah after I brought it up it doesn't really make sense to do except under a flag/canary release for a browser and that would only be at minimum stage 3 by definition anyway.

We would only do this if you were using that for development and wanted the clearer output etc instead if source maps or something - not really a priority unless someone wants to take this on.

hzoo commented Oct 8, 2016

Ok yeah it makes sense to just support all plugins in latest ( - currently up to es2017.

@hzoo hzoo closed this Oct 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment