New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename stage presets to indicate the danger of using them #4914

Closed
kentcdodds opened this Issue Nov 30, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@kentcdodds
Member

kentcdodds commented Nov 30, 2016

As noted here.

@kentcdodds: What if instead of stage-0, stage-1 we called them super-dangerous pretty-dangerous, etc :)
@DrewML: Honestly, I personally would love that. You have to acknowledge what you're doing everytime you open up package.json/.babelrc

I'm a fan of this idea. Though I think that people might not like this change much. Thoughts?

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Dec 2, 2016

Stage 0 is “i’ve got a crazy idea”, stage 1 is “this idea might not be stupid”, stage 2 is “let’s use polyfills and transpilers to play with it, and stage 3 is “let’s let browsers implement it and see how it goes", and stage 4 is "now it's javascript".

Coming up with more accurate names that strongly discourage relying on features in production too early would be great. At Airbnb, we only permit using stage 3 features or higher, because of the high risk of breaking change (or total withdrawal) of stage 2-and-below features.

ljharb commented Dec 2, 2016

Stage 0 is “i’ve got a crazy idea”, stage 1 is “this idea might not be stupid”, stage 2 is “let’s use polyfills and transpilers to play with it, and stage 3 is “let’s let browsers implement it and see how it goes", and stage 4 is "now it's javascript".

Coming up with more accurate names that strongly discourage relying on features in production too early would be great. At Airbnb, we only permit using stage 3 features or higher, because of the high risk of breaking change (or total withdrawal) of stage 2-and-below features.

@hzoo hzoo added the i: discussion label Dec 2, 2016

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Dec 2, 2016

Member

https://twitter.com/littlecalculist/status/627186686796021761 from @dherman

Stage 0: Aspirational
Stage 1: Experimental
Stage 2: Userland Early Adoption
Stage 3: Browser Early Adoption
Stage 4: Frozen

We can definetely change our wording, docs around this even if you can always include each transform individually to get around it.

@jugglinmike wrote in https://bocoup.com/weblog/javascript-developers-watch-your-language about this as well.

I don't here about these concerns myself too much so just didn't know about it? I'm sure were glad to be more involved in the process.

Member

hzoo commented Dec 2, 2016

https://twitter.com/littlecalculist/status/627186686796021761 from @dherman

Stage 0: Aspirational
Stage 1: Experimental
Stage 2: Userland Early Adoption
Stage 3: Browser Early Adoption
Stage 4: Frozen

We can definetely change our wording, docs around this even if you can always include each transform individually to get around it.

@jugglinmike wrote in https://bocoup.com/weblog/javascript-developers-watch-your-language about this as well.

I don't here about these concerns myself too much so just didn't know about it? I'm sure were glad to be more involved in the process.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Dec 4, 2016

Member

I definitely want to keep the presets. And we should probably have the name indicate the proposals process in some way, otherwise it wont make a lot of sense (ie babel-preset-experimental doesn't really say: "I transpile potential standard features" to me).

Maybe:

  • babel-preset-aspirational-stage-0
  • babel-preset-experimental-stage-1
  • babel-preset-very-early-adoption-stage-2
  • babel-preset-early-adoption-stage-3
  • babel-preset-frozen-stage-4

I'm not a huge fan honestly... Maybe something like this?

  • babel-preset-extremely-dangerous-stage-0
  • babel-preset-dangerous-stage-1
  • babel-preset-risky-stage-2
  • babel-preset-solid-stage-3
  • babel-preset-frozen-stage-4

Or something. Harkens to dangerouslySetInnerHTML or __SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__ ;-)

Member

kentcdodds commented Dec 4, 2016

I definitely want to keep the presets. And we should probably have the name indicate the proposals process in some way, otherwise it wont make a lot of sense (ie babel-preset-experimental doesn't really say: "I transpile potential standard features" to me).

Maybe:

  • babel-preset-aspirational-stage-0
  • babel-preset-experimental-stage-1
  • babel-preset-very-early-adoption-stage-2
  • babel-preset-early-adoption-stage-3
  • babel-preset-frozen-stage-4

I'm not a huge fan honestly... Maybe something like this?

  • babel-preset-extremely-dangerous-stage-0
  • babel-preset-dangerous-stage-1
  • babel-preset-risky-stage-2
  • babel-preset-solid-stage-3
  • babel-preset-frozen-stage-4

Or something. Harkens to dangerouslySetInnerHTML or __SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__ ;-)

@glenjamin

This comment has been minimized.

Show comment
Hide comment
@glenjamin

glenjamin Dec 4, 2016

Aside from back-compat (which renaming would break anyway), what is the advantage of using a stage preset over opting in to specific desired features?

I often see people go "I want object rest, and that's stage 2, so I enabled stage 2". They now have a load of other experimental features enabled they might not know about and probably don't need.

Especially at the lower stages, not all transforms at the same stage are as reliable or likely to change / move forwards.

Also, as stages change over time then people who aren't using shrinkwrap or yarn will get new features appearing, possibly without their knowledge. If a feature is canned they might even get one vanishing.

I definitely think people should be discouraged from using stage presets, and perhaps they should be removed entirely.

glenjamin commented Dec 4, 2016

Aside from back-compat (which renaming would break anyway), what is the advantage of using a stage preset over opting in to specific desired features?

I often see people go "I want object rest, and that's stage 2, so I enabled stage 2". They now have a load of other experimental features enabled they might not know about and probably don't need.

Especially at the lower stages, not all transforms at the same stage are as reliable or likely to change / move forwards.

Also, as stages change over time then people who aren't using shrinkwrap or yarn will get new features appearing, possibly without their knowledge. If a feature is canned they might even get one vanishing.

I definitely think people should be discouraged from using stage presets, and perhaps they should be removed entirely.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Dec 4, 2016

Member

Yeah, the more I think about it, the more I'm convinced that I'd rather remove the stage presets than rename them to something odd. Honestly, I'd personally create my own presets based on my personal preferences (like I do with ESLint). So I guess I'm good to vote we do away with the stage presets.

Member

kentcdodds commented Dec 4, 2016

Yeah, the more I think about it, the more I'm convinced that I'd rather remove the stage presets than rename them to something odd. Honestly, I'd personally create my own presets based on my personal preferences (like I do with ESLint). So I guess I'm good to vote we do away with the stage presets.

@DrewML

This comment has been minimized.

Show comment
Hide comment
@DrewML

DrewML Dec 5, 2016

Member

@hzoo has brought up the idea in the past that we have a babel-init package (or a babel init command) that can be used to setup your .babelrc (bonus would be if it could also edit an existing config). I think, if we provide the ability to enable/disable official plugins that way, it would alleviate the complaints that the stage groupings addressed ("this takes too much work to setup").

@hzoo and @thejameskyle also voiced desire to get rid of stage presets on Slack.

Member

DrewML commented Dec 5, 2016

@hzoo has brought up the idea in the past that we have a babel-init package (or a babel init command) that can be used to setup your .babelrc (bonus would be if it could also edit an existing config). I think, if we provide the ability to enable/disable official plugins that way, it would alleviate the complaints that the stage groupings addressed ("this takes too much work to setup").

@hzoo and @thejameskyle also voiced desire to get rid of stage presets on Slack.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Dec 5, 2016

Member

Doing an RFC issue for this could be useful (or turning this issue into it)

  • summary, motivation, implementation (or none in this case for removing), tradeoffs, questions etc
Member

hzoo commented Dec 5, 2016

Doing an RFC issue for this could be useful (or turning this issue into it)

  • summary, motivation, implementation (or none in this case for removing), tradeoffs, questions etc
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Feb 21, 2017

Member

Alright I think it's best to remove rather than rename. If anything I think we should republish with an error so that people aren't as confused when they try to install it? This is similar to #4955 so going to close and merge into that.

And yeah we should still do babel init

Wrote up part of this in babel/website#1166 (please review 😄 )

Member

hzoo commented Feb 21, 2017

Alright I think it's best to remove rather than rename. If anything I think we should republish with an error so that people aren't as confused when they try to install it? This is similar to #4955 so going to close and merge into that.

And yeah we should still do babel init

Wrote up part of this in babel/website#1166 (please review 😄 )

@hzoo hzoo closed this Feb 21, 2017

@lock lock bot added the outdated label May 5, 2018

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2018

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