Issue 1:
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.

Issue 2:
So there's a problem with how stage-x plugins are designed right now. They are versioned in lockstep with the rest of Babel. However these stage-x features change throughout the process and may make breaking changes at any time.

Babel's lockstep versioning causes a weird tradeoff of either following SemVer or keeping up with the spec. At the same time Lockstep versioning is important for the ecosystem.

I've talked to contributors privately about this and figured I'd create an issue:

I want to get rid of the babel-preset-stage-x plugins and move all of the stage-x plugins into their own monorepo with independent (see Lerna) versioning.

This way there are no more presets for stages and people have to manually enable plugins by individual features. These plugins can then make major version bumps at any time.

The plugins should be named babel-plugin-transform-proposal-{feature}, when they are accepted by TC39 they move into the main repository and are named babel-plugin-transform-es{year}-{feature} and included in the relevant presets.

The one problem that needs to be solved is parsing. We need to be able to change the syntax of a proposal at any time so that we can track changes like decorators moving from @ to # (which was turned down by the committee but we need a better way in Babel to handle that type of scenario).

Babylon has the ability to write syntax features as plugins (see https://github.com/babel/babylon/tree/master/src/plugins), but right now es proposals are embedded within the parser. Instead we should build es proposal syntax as plugins.

Right now Babylon does not allow external plugins to be added in order to prevent the ecosystem from going mad with power using them.

I would like to suggest adding a whitelist to Babylon for allowed parser plugins in Babylon and allowing them to be included in Babel plugins like:

export default function babelPlugin() {
return {
__internal_only_dont_use_this_or_we_will__find_you_and_intentionally_break_your_plugin_in_a_patch_release__you_have_been_warned__: {
__dangerous_dont_use__: {
__seriously_no__: {
__just_fork_babylon_yourself__: {
parserPlugin: { name: 'proposal-{feature}', version: require('./package.json').version, babelVersions: '^6.0.0', plugin: require('./parser-plugin') }
}
}
}
}
};
}

I think that should be enough.

It's gonna be controversial to remove the stage presets, but it is the right thing to do for the ecosystem in my opinion.