Extract targets parser and compat data from preset-env

[nicolo-ribaudo]

Q	A
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This is PR only moves code around, to expose as public packages internal API which are already used by some Babel integrations:

• https://github.com/vuejs/vue-cli/blob/00acca5f14be9f69b763ba4b755c6290368cae2c/packages/%40vue/babel-preset-app/index.js#L19
• https://github.com/babel/ember-cli-babel/blob/fb97b9fddc598786558f8ce8cfc70882b6fb9618/index.js#L468
• https://github.com/babel/ember-cli-babel/blob/fb97b9fddc598786558f8ce8cfc70882b6fb9618/index.js#L203
  Otherwise, they will have problems in Babel 8 with Disable submodule exports #10850.

I created two new packages: @babel/compat-data and @babel/helper-compilation-targets.
I wasn't sure about where to put the info about overlapping plugins which will be useful for preset-modules (I put it in @babel/compat-data) and about the mappings from transform plugins to syntax plugins (I left it in @babel/preset-env).

[loganfsmyth]

I swear at this point we should just append a random UUID to every filename except index.js on publish :P

[nicolo-ribaudo]

Did you see #10850? 😛

[loganfsmyth]

Hah, nope! Had no idea that was a thing Node allowed!

[JLHwung]

Can we just require @babel/helper-compilation-targets?

[nicolo-ribaudo]

Good catch; I'll update it. Note that this file isn't published to npm so it isn't a problem, but using @babel/helper-compilation-targets is more clear.

[JLHwung]

Maybe "Engine compat data used in @babel/preset-env"?

[existentialism]

Any reason to not also move isPluginRequired as another primitive to the helper?

In fact, erring on the side of less packages to maintain, can we just have one package that exports getTargets, our plugin/target data and something like:

isRequired(
  name: string,
  targetEnvironments: Targets,
  options: {
    compatData?: { [key in string]: Targets }
    // ...
  }
) { ... }

This seems like a key use-case (as both vue/ember use it), and would allow anyone to pass their own mappings in, if they wanted.

[nicolo-ribaudo]

Any reason to not also move isPluginRequired as another primitive to the helper?

Maybe I forgot it, I'll check.

In fact, erring on the side of less packages to maintain

I don't think that this should be a goal? The maintenance cost of 2 packages in a monorepo is exactly the same as 1 package.

I created two separate packages because, if we are going to disable sub-package imports in Babel 8.0.0, @babel/compat-data will already be an exception when you can import internal files. If we merge it with the helper package, then some internal files will be importable while others won't, and I think that it would be more confusing.

[nicolo-ribaudo]

Oh, I already extracted it. I called it isItemRequired because it's not just used for plugins, but also for polyfills. Maybe I should choose another name?

[existentialism]

Ah missed that. I think the name is fine.

[nicolo-ribaudo]

Whops I accidentally deleted my comment.

I wrote that I agree that the proposed isRequired function would be used both by ember and vue. However, I still think that the data should stay separated in a "data-only" package for direct usage.

Also, do you think that isRequired should default to using the plugins and core-js 2 data, or just the plugins data? And then there is also core-js 3, which keeps its data in a separate package.
(I think that it should only use plugins data)

[existentialism]

The maintenance cost of 2 packages in a monorepo is exactly the same as 1 package.

I'm not sure I agree with that... perhaps mechanically, but I think we should always consider the balance between a package's public API vs. adding more packages.

Also, do you think that isRequired should default to using the plugins and core-js 2 data, or just the plugins data? And then there is also core-js 3, which keeps its data in a separate package.

I think we can go with just plugins data for now.

[nicolo-ribaudo]

@existentialism I ended up not exporting isItemRequired (which I also renamed) to avoid confusion with isRequired.