Move preset-env into @babel/core

[hzoo]

Quick notes so not an RFC but just wanted to track. Relates to or depends on #2 which moves the targets config to @babel/core. Just taking that idea further.

Not a new idea by any means, just haven't seriously considered it since it changes how people think about it so much (I think for the better).

Just means you don't need to install a package, configure the use of the preset, or track the versions (a big deal, even when comparing to other tools in this space -> whether it's Babel 5, esbuild,sucrase,buble,swc,typescript,etc). It is confusing that you have to install the package as well as configure it in the config.

I Assume that most people who use Babel intend to use this preset currently and if not, we want them too? Why not just include it then, with some way of opt-out for tooling, special builds, or people that want to do something else.

Can we do this in a minor version? Maybe doesn't apply unless you use the new top-level targets option.
I think this was kinda my intention from the start but it took a while to get this in place and we forgot to just do this a long time ago? Similar to preset-modules, preset-env was an experiment, then a separate repo, and replaced preset-latest/es2015/etc.
Means that plugins (other than tc39 proposals) would be built-in to babel once again (babel 5), although we could keep them separate for organizational purposes. Should help somewhat with the versioning/install/dep we've had for a long time.

// existing config
{
  "presets": [
    ["@babel/preset-env", {
      "targets": ">1%, not ie 11"
    }]
  ]
}

// move targets into core https://github.com/babel/rfcs/pull/2
{
  "targets": ">1%, not ie 11",
  "presets": ["@babel/preset-env"]
}

// this proposal (targets can have some default in v8) but in v7 if this is done in a minor it can be undefined/false
{
  "targets": ">1%, not ie 11"
}

[coreyfarrell]

nyc currently uses the transform function from @babel/core to add instrumentation, it would never be appropriate for nyc to perform preset-env transformations. npm i nyc currently installs an 18mb node_modules on my system, npm i nyc @babel/preset-env installs 28mb. A 50% size increase for a feature that nyc will never use would be unfortunate. If babel were to proceed with bundling @babel/preset-env into @babel/core I'd likely switch our code back to using the individual babel parser/traverse/types/generator modules directly as we had in the past.

I want to stress I respect whatever decision babel developers make, I understand nyc is only one user and we do have an escape hatch of directly using the individual modules. Just saw this proposal so I wanted to share my prospective.

[nicolo-ribaudo]

@coreyfarrell Supporting use cases different from "the default one" is definitely something that we'll think about: while Babel is mostly used to compile modern code to older versions, we as a team have always tried to present it as a general-purpose transformation tool.