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

Should we remove Stage 0 - 2 presets, leaving only stage 3? #7770

Closed
loganfsmyth opened this Issue Apr 21, 2018 · 21 comments

Comments

Projects
None yet
@loganfsmyth
Member

loganfsmyth commented Apr 21, 2018

EDIT: PR at #8293

Stage-0 Readme: https://github.com/babel/babel/blob/48fe688a10d83486defdda223ac8d8d88057975d/packages/babel-preset-stage-0/README.md#babelpreset-stage-0

Can migrate automatically now with https://github.com/babel/babel-upgrade (npx babel-upgrade) as of babel/babel-upgrade#69


I think there's a reasonable argument to be made for stage 3 features being easily toggle-able, and by that point they are less likely to have major breaking changes, so I'm not as against it. We've had occasional conversations, but I think we should decide.

The stage < 3 presets are likely to change over time, making versioning difficult for them, and the community has grown to overactively enable stage-0 which I see as a dangerous precedent. To me it seems like we should remove these presets and instead use documentation to encourage people to enable experimental plugins on a case-by-case basis for the ones they actually want, rather than just enabling everything for the sake of it.

I just want to make sure we have this conversation while we have the easy opportunity of dropping them before 7.x.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Apr 21, 2018

Member

I'll add that the new decoratorsLegacy option for stage-2 to toggle decorator behavior is a good example of why they are annoying right now. If people aren't even using decorators in the first place, we still currently force them to choose which version of decorators they will want.

Member

loganfsmyth commented Apr 21, 2018

I'll add that the new decoratorsLegacy option for stage-2 to toggle decorator behavior is a good example of why they are annoying right now. If people aren't even using decorators in the first place, we still currently force them to choose which version of decorators they will want.

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Apr 21, 2018

Member

Also, people shouldn't be required to know what stages are and which stage a particular feature is.

Member

nicolo-ribaudo commented Apr 21, 2018

Also, people shouldn't be required to know what stages are and which stage a particular feature is.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Apr 21, 2018

Member

Duplicate of #4955 too (it's been that long 😄)

Some context: I added it in v6 initially for backwards compatibility with v5 equivalent, and to showcase an example of making your own presets.

One reason we may want to do this is just because people don't understand what each Stage means (I mean even on TC39 we still kinda aren't sure at times), since it's just an arbitrary #.

The reason I wanted to keep it before was because we would do some kind of warning (and it's easy enough to just bump the version if the proposal updates) and that people would make their own unofficial stage presets that would make things worse, but yeah maybe in the end that's just not enough of an issue. And really we have an issue that it seems like people don't even know that you can make your own presets/plugins in the first place? I guess I got (wrongly) concerned about the whole "making it easy" to configure babel when in the end it's just inherently going to be complicated because we don't know what you want. To that end maybe it's ok for someone (or us) to have that preset/tool I was thinking of that opts you in to everything for those that just want to use it and not care about the output. For everyone else, it makes sense that you should have to know what each thing does because it's important and not just some arbitrary thing you have to learn.

Yeah maybe trying so hard to make it convenient leads to the exact issue we are trying to fix. In the meantime we have things like create-react-app and others that abstract babel away completely anyway.

But yeah we need more docs, and then better suggestions depending on the person's usecase.

I think it's fine to drop whenever really since it's a package not a breaking change but I understand what you are saying.

Maybe I was the only one that wanted to keep it, and I guess it's more of a fear/workaround rather than the real solution anyway. I don't think anyone on TC39 likes it either.

also a poll I did earlier

Member

hzoo commented Apr 21, 2018

Duplicate of #4955 too (it's been that long 😄)

Some context: I added it in v6 initially for backwards compatibility with v5 equivalent, and to showcase an example of making your own presets.

One reason we may want to do this is just because people don't understand what each Stage means (I mean even on TC39 we still kinda aren't sure at times), since it's just an arbitrary #.

The reason I wanted to keep it before was because we would do some kind of warning (and it's easy enough to just bump the version if the proposal updates) and that people would make their own unofficial stage presets that would make things worse, but yeah maybe in the end that's just not enough of an issue. And really we have an issue that it seems like people don't even know that you can make your own presets/plugins in the first place? I guess I got (wrongly) concerned about the whole "making it easy" to configure babel when in the end it's just inherently going to be complicated because we don't know what you want. To that end maybe it's ok for someone (or us) to have that preset/tool I was thinking of that opts you in to everything for those that just want to use it and not care about the output. For everyone else, it makes sense that you should have to know what each thing does because it's important and not just some arbitrary thing you have to learn.

Yeah maybe trying so hard to make it convenient leads to the exact issue we are trying to fix. In the meantime we have things like create-react-app and others that abstract babel away completely anyway.

But yeah we need more docs, and then better suggestions depending on the person's usecase.

I think it's fine to drop whenever really since it's a package not a breaking change but I understand what you are saying.

Maybe I was the only one that wanted to keep it, and I guess it's more of a fear/workaround rather than the real solution anyway. I don't think anyone on TC39 likes it either.

also a poll I did earlier

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Apr 22, 2018

Nobody should be using anything prior to stage 3 in production, so i think removing them would be excellent.

Those who want to help proposals advance, and experiment, can handle whatever configuration burden ends up being necessary.

ljharb commented Apr 22, 2018

Nobody should be using anything prior to stage 3 in production, so i think removing them would be excellent.

Those who want to help proposals advance, and experiment, can handle whatever configuration burden ends up being necessary.

@dczombera

This comment has been minimized.

Show comment
Hide comment
@dczombera

dczombera Apr 23, 2018

Contributor

Being new to the project here is my (naive?) humble opinion. The Stage 3 spec quality is described as Complete: all semantics, syntax and API are completed described, while Stage 2 is Draft: all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected. From my perspective this means Stage 3 is pretty stable (correct me if I'm wrong) and it makes sense to have a preset for that.
Everything that is < Stage 3 is experimental and if you really want to use that awesome new feature (e.g. pattern matching) you should "opt-in" for that feature, i.e. enable it case-by-case assuming you know what you are doing.
Please correct if anything I just wrote is wrong. 😅

Contributor

dczombera commented Apr 23, 2018

Being new to the project here is my (naive?) humble opinion. The Stage 3 spec quality is described as Complete: all semantics, syntax and API are completed described, while Stage 2 is Draft: all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected. From my perspective this means Stage 3 is pretty stable (correct me if I'm wrong) and it makes sense to have a preset for that.
Everything that is < Stage 3 is experimental and if you really want to use that awesome new feature (e.g. pattern matching) you should "opt-in" for that feature, i.e. enable it case-by-case assuming you know what you are doing.
Please correct if anything I just wrote is wrong. 😅

@mAAdhaTTah

This comment has been minimized.

Show comment
Hide comment
@mAAdhaTTah

mAAdhaTTah Apr 26, 2018

Contributor

I agree with this, but by similar logic, might be worth killing off the year-specific presets as well?

Contributor

mAAdhaTTah commented Apr 26, 2018

I agree with this, but by similar logic, might be worth killing off the year-specific presets as well?

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Apr 26, 2018

The year-specific presets match what's actually in the spec, and are still useful (altho using env is better).

ljharb commented Apr 26, 2018

The year-specific presets match what's actually in the spec, and are still useful (altho using env is better).

@jridgewell

This comment has been minimized.

Show comment
Hide comment
@jridgewell

jridgewell Apr 26, 2018

Member

We definitely should keep yearly presets, though you should be using env.

👍to killing Stage 0-2.

Member

jridgewell commented Apr 26, 2018

We definitely should keep yearly presets, though you should be using env.

👍to killing Stage 0-2.

@NullDivision

This comment has been minimized.

Show comment
Hide comment
@NullDivision

NullDivision May 16, 2018

I understand the motivation behind this discussion, however I think what most of the people who are calling to remove stages 0 through 2 (most likely because of an inability to manage project specs) fail to realize is that stages are not code switches.

Stage-X is a preset. A group of plugins. They are not a part of Babel but of TC39 specs. All Babel is doing is creating a copy of plugins for that spec.

Removing the presets doesn't prevent usage of the underlying plugins. It prevents visibility. Say you remove stages 0-2. A startup comes along and feels like using non-standards plugins is fine. They will use it.

At least with stages it's managed by a trusted source instead of ~/npm/awesome-babel/babel-preset-latest

NullDivision commented May 16, 2018

I understand the motivation behind this discussion, however I think what most of the people who are calling to remove stages 0 through 2 (most likely because of an inability to manage project specs) fail to realize is that stages are not code switches.

Stage-X is a preset. A group of plugins. They are not a part of Babel but of TC39 specs. All Babel is doing is creating a copy of plugins for that spec.

Removing the presets doesn't prevent usage of the underlying plugins. It prevents visibility. Say you remove stages 0-2. A startup comes along and feels like using non-standards plugins is fine. They will use it.

At least with stages it's managed by a trusted source instead of ~/npm/awesome-babel/babel-preset-latest

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth May 16, 2018

Member

Removing the presets doesn't prevent usage of the underlying plugins. It prevents visibility. Say you remove stages 0-2. A startup comes along and feels like using non-standards plugins is fine. They will use it.

That's pretty much the goal I'm aiming for. I want people to be able to use things, but I also want them to think about what they are using.

At least with stages it's managed by a trusted source instead of ~/npm/awesome-babel/babel-preset-latest

If they want to use an alternative preset, they are totally free to do so. The fact that the name isn't @babel/ and therefor a "trusted source" is specifically what I'd like, because if people want to use experimental proposals, it's much better if they opt into them specifically. If they want to use a random other preset, this makes it easier to see that it's not something we recommend.

Member

loganfsmyth commented May 16, 2018

Removing the presets doesn't prevent usage of the underlying plugins. It prevents visibility. Say you remove stages 0-2. A startup comes along and feels like using non-standards plugins is fine. They will use it.

That's pretty much the goal I'm aiming for. I want people to be able to use things, but I also want them to think about what they are using.

At least with stages it's managed by a trusted source instead of ~/npm/awesome-babel/babel-preset-latest

If they want to use an alternative preset, they are totally free to do so. The fact that the name isn't @babel/ and therefor a "trusted source" is specifically what I'd like, because if people want to use experimental proposals, it's much better if they opt into them specifically. If they want to use a random other preset, this makes it easier to see that it's not something we recommend.

@NullDivision

This comment has been minimized.

Show comment
Hide comment
@NullDivision

NullDivision May 16, 2018

But the issue is that developers are people. More precisely very lazy people. Meaning that they will always choose the shortest route. They'll use a plugin made by "that one guy on GitHub" instead. And if "that guy" makes a kitchen sink preset then that's what they'll use.

NullDivision commented May 16, 2018

But the issue is that developers are people. More precisely very lazy people. Meaning that they will always choose the shortest route. They'll use a plugin made by "that one guy on GitHub" instead. And if "that guy" makes a kitchen sink preset then that's what they'll use.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth May 16, 2018

Member

I don't necessarily see that as a problem.

Member

loganfsmyth commented May 16, 2018

I don't necessarily see that as a problem.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal May 25, 2018

I appreciate you opening this to discussion. I’m skeptical of what I see as an “abstinence” approach to Stage 0 and 1, if I understand the issue correctly, and I may not.

Is the suggestion to stop updates to the stage-0 and stage-1 presets? This seems unhelpful, because 1. developers historically coalesce around emerging patterns and will continue to do so, which predicates this issue; and because 2. removing these stage presets from your administration would be a step “backward” for the feedback loop you are establishing between developers and the standards bodies.

Here are a few related notes from The Extensible Web Manifesto (emphasis added):

  • Developers can ramp up more quickly on new APIs, providing quicker feedback to the platform while the APIs are still the most malleable.
  • Mistakes in APIs can be corrected quickly by the developers who use them, and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.
  • Library authors can experiment with new APIs and create more cow-paths for the platform to pave.

Expanding on my first point; if new Stage 0 and Stage 1 plugins are developed, would you consider it too far a logical leap to expect those plugins to be made into community PRs for the official stage-0 and stage-1 presets? And if those PRs were ignored or declined, do I presume too much to suggest an alternative project would birth? If those are reasonable presumptions, what does the babel team identify as the pros and cons?

To that end, I hope you will then consider my second point; While it may not be an issue to see the community develop their own babel-preset-dangerzone, I don’t think this provides them a net benefit. This alternative would merely be one step further from “the metal”, so to speak, as this preset would be something maintained one step further from babel and the TC39.

Thanks for considering my questions and concerns. I have benefited enormously from your hard work.

jonathantneal commented May 25, 2018

I appreciate you opening this to discussion. I’m skeptical of what I see as an “abstinence” approach to Stage 0 and 1, if I understand the issue correctly, and I may not.

Is the suggestion to stop updates to the stage-0 and stage-1 presets? This seems unhelpful, because 1. developers historically coalesce around emerging patterns and will continue to do so, which predicates this issue; and because 2. removing these stage presets from your administration would be a step “backward” for the feedback loop you are establishing between developers and the standards bodies.

Here are a few related notes from The Extensible Web Manifesto (emphasis added):

  • Developers can ramp up more quickly on new APIs, providing quicker feedback to the platform while the APIs are still the most malleable.
  • Mistakes in APIs can be corrected quickly by the developers who use them, and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.
  • Library authors can experiment with new APIs and create more cow-paths for the platform to pave.

Expanding on my first point; if new Stage 0 and Stage 1 plugins are developed, would you consider it too far a logical leap to expect those plugins to be made into community PRs for the official stage-0 and stage-1 presets? And if those PRs were ignored or declined, do I presume too much to suggest an alternative project would birth? If those are reasonable presumptions, what does the babel team identify as the pros and cons?

To that end, I hope you will then consider my second point; While it may not be an issue to see the community develop their own babel-preset-dangerzone, I don’t think this provides them a net benefit. This alternative would merely be one step further from “the metal”, so to speak, as this preset would be something maintained one step further from babel and the TC39.

Thanks for considering my questions and concerns. I have benefited enormously from your hard work.

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb May 25, 2018

The issue is that basically nothing in stage 0 or 1 is anywhere close to being ready to experiment with, because it's still subject to massive change. The best thing is for the majority of devs to not use these at all until they're at least at stage 2; ideally at stage 3. Experimenting with early-stage things should be hard, because it's not intended for casual use.

ljharb commented May 25, 2018

The issue is that basically nothing in stage 0 or 1 is anywhere close to being ready to experiment with, because it's still subject to massive change. The best thing is for the majority of devs to not use these at all until they're at least at stage 2; ideally at stage 3. Experimenting with early-stage things should be hard, because it's not intended for casual use.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo May 25, 2018

Member

Oh I didn't update this thread but we are going to remove the Stage 0-2 presets. I'm planning on writing something long form to explain. It's not worth having them anymore or updating them (even with my previous fear of community driven one) because each one is breaking/unstable, and people don't understand what "stage-0' means as a string (no one even bothers to read the package.json) so opting in explicitly is better.

Member

hzoo commented May 25, 2018

Oh I didn't update this thread but we are going to remove the Stage 0-2 presets. I'm planning on writing something long form to explain. It's not worth having them anymore or updating them (even with my previous fear of community driven one) because each one is breaking/unstable, and people don't understand what "stage-0' means as a string (no one even bothers to read the package.json) so opting in explicitly is better.

@hzoo hzoo added this to the Babel 7 RC milestone May 29, 2018

@robertrossmann

This comment has been minimized.

Show comment
Hide comment
@robertrossmann

robertrossmann Jun 5, 2018

Contributor

As an external observer, I agree with removing the stage 0-2 presets as it would seem that using early-stage code features should really be done only after careful evaluation.

Aside from that, it sounds that the main motivation for removing these presets stems from the feeling that many developers do not bother to understand what they are bringing in to the language by installing a transform/plugin and that these new language features may change drastically in the future - in that case, I would recommend adding a warning when a stage 0-2 plugin is installed:

WARNING: This plugin allows you to use syntax which may change drastically before being accepted as part of the language, use at your own risk ⚠️

Now the developer has been warned properly and they will have the opportunity to "think twice" before using this preset/plugin.

Contributor

robertrossmann commented Jun 5, 2018

As an external observer, I agree with removing the stage 0-2 presets as it would seem that using early-stage code features should really be done only after careful evaluation.

Aside from that, it sounds that the main motivation for removing these presets stems from the feeling that many developers do not bother to understand what they are bringing in to the language by installing a transform/plugin and that these new language features may change drastically in the future - in that case, I would recommend adding a warning when a stage 0-2 plugin is installed:

WARNING: This plugin allows you to use syntax which may change drastically before being accepted as part of the language, use at your own risk ⚠️

Now the developer has been warned properly and they will have the opportunity to "think twice" before using this preset/plugin.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 6, 2018

Member

Ok as of https://github.com/babel/babel/releases/tag/v7.0.0-beta.52, I ran npm deprecate on the yearly/stage presets. Will be annoying for anyone using ^ which we have recommended against while in pre-release but that's why we are just doing it for the latest release to give people time if you are already on v7. If someone wants all the plugins, or the equivalent, you are always able to make your own preset.

Can remove in the next release, https://github.com/babel/notes/blob/master/2018/2018-07/july-02.md#rc

Member

hzoo commented Jul 6, 2018

Ok as of https://github.com/babel/babel/releases/tag/v7.0.0-beta.52, I ran npm deprecate on the yearly/stage presets. Will be annoying for anyone using ^ which we have recommended against while in pre-release but that's why we are just doing it for the latest release to give people time if you are already on v7. If someone wants all the plugins, or the equivalent, you are always able to make your own preset.

Can remove in the next release, https://github.com/babel/notes/blob/master/2018/2018-07/july-02.md#rc

@hzoo hzoo referenced this issue Jul 9, 2018

Merged

Remove Stage presets #8293

5 of 6 tasks complete
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 10, 2018

Member

Made #8293

Member

hzoo commented Jul 10, 2018

Made #8293

@crrobinson14

This comment has been minimized.

Show comment
Hide comment
@crrobinson14

crrobinson14 Jul 23, 2018

Usage of a Babel preset now directs users to this thread. But this thread doesn't contain a specific instruction or recommendation to users on what to change. This is just going to invite "please guide me" requests into what seems to me to be a dev-oriented discussion.

Shouldn't the command line warning redirect to a page like https://new.babeljs.io/docs/en/next/v7-migration.html with some instructions added on how to make the change?

crrobinson14 commented Jul 23, 2018

Usage of a Babel preset now directs users to this thread. But this thread doesn't contain a specific instruction or recommendation to users on what to change. This is just going to invite "please guide me" requests into what seems to me to be a dev-oriented discussion.

Shouldn't the command line warning redirect to a page like https://new.babeljs.io/docs/en/next/v7-migration.html with some instructions added on how to make the change?

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 24, 2018

Member

Oh sorry about that, we didn't merge the PR yet but I added some links at the top of thread. The instructions are to replace the use of the preset and to opt in to using the specific proposals you desire to use, which we've listed in https://github.com/babel/babel/blob/48fe688a10d83486defdda223ac8d8d88057975d/packages/babel-preset-stage-0/README.md#babelpreset-stage-0.

babel-upgrade PR: babel/babel-upgrade#69

Member

hzoo commented Jul 24, 2018

Oh sorry about that, we didn't merge the PR yet but I added some links at the top of thread. The instructions are to replace the use of the preset and to opt in to using the specific proposals you desire to use, which we've listed in https://github.com/babel/babel/blob/48fe688a10d83486defdda223ac8d8d88057975d/packages/babel-preset-stage-0/README.md#babelpreset-stage-0.

babel-upgrade PR: babel/babel-upgrade#69

@hzoo hzoo closed this in #8293 Jul 24, 2018

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 25, 2018

Member

Ok after merging babel/babel-upgrade#69, babel-upgrade should do this for you (although it copies every proposal in the Stage and should figure out if you want to use all of them).

And you may want to create a preset on your own instead of duplicating the same thing in each project as well.

Member

hzoo commented Jul 25, 2018

Ok after merging babel/babel-upgrade#69, babel-upgrade should do this for you (although it copies every proposal in the Stage and should figure out if you want to use all of them).

And you may want to create a preset on your own instead of duplicating the same thing in each project as well.

@mmarkelov mmarkelov referenced this issue Jul 30, 2018

Closed

Update babel #1652

tvaliasek added a commit to tvaliasek/webpack that referenced this issue Aug 6, 2018

Update babel.config.js
stage presets were removed in current babel 7

babel/babel#7770
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment