This repository has been archived by the owner. It is now read-only.

How to handle stage-x #14

Closed
hzoo opened this Issue Oct 7, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@hzoo
Member

hzoo commented Oct 7, 2016

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
      }
    }],
    "stage-2"
  ]
}

Actually now that I think about that seems fine?

@hzoo hzoo added the i: discussion label Oct 7, 2016

@milesj

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj 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.

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.
@AvivRubys

This comment has been minimized.

Show comment
Hide comment
@AvivRubys

AvivRubys Oct 7, 2016

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?

AvivRubys commented Oct 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Oct 7, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Oct 8, 2016

Member

Ok yeah it makes sense to just support all plugins in latest (http://babeljs.io/docs/plugins/preset-latest/) - currently up to es2017.

Member

hzoo commented Oct 8, 2016

Ok yeah it makes sense to just support all plugins in latest (http://babeljs.io/docs/plugins/preset-latest/) - currently up to es2017.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.