preset-env include default export-namespace-from

[monic-shixi]

In the https://babeljs.io/blog/2020/07/30/7.11.0

If you were directly using any of

• @babel/plugin-proposal-export-ns-from

(ps: I think this is a typo? @babel/plugin-proposal-export-namespace-from?)

• @babel/plugin-proposal-logical-assignment-operators

• @babel/plugin-proposal-numeric-separators

you can remove them from your config as they will be included by default:

{
 "presets": [
   ["@babel/env", { "targets": ["defaults"] }]
 ],
 "plugins": [
-   "@babel/plugin-proposal-export-namespace-from",
-   "@babel/plugin-proposal-logical-assignment-operators",
-   "@babel/plugin-proposal-numeric-separators"
 ]
}

• @babel/plugin-proposal-export-namespace-from

https://github.com/babel/babel/blob/v7.11.0/packages/babel-preset-env/src/index.js#L137

if (shouldTransformExportNamespaceFrom) {
  modulesPluginNames.push("proposal-export-namespace-from");
} else {
  modulesPluginNames.push("syntax-export-namespace-from");
}

If want to use this by default, why not push proposal-export-namespace-from directly.

And the blog said:

Note: babel-loader and @rollup/plugin-babel don't yet tell Babel they supports this syntax, but we are working on it with the relevant maintainers.

So, current the caller always be undefined.

And https://babeljs.io/docs/en/options#primary-options said :

Users of Babel's integrations, like babel-loader or @babel/register are unlikely to use these.

May i think the above shouldTransformExportNamespaceFrom is just to compatible with caller syntax in the near future? And, if caller been supported, does the preset-env include @babel/plugin-proposal-export-namespace-from by default ? (Or the default includes mean is use the default config as premise(work by babel-loader and @rollup/plugin-babel))

[JLHwung]

If want to use this by default, why not push proposal-export-namespace-from directly.

shouldTransformExportNamespaceFrom is determined by modules, api.caller and targets.

• When modules is false and targets supports export * as ns, shouldTransformExportNamespaceFrom is false since the compiled targets already supports export * as ns.
• When modules is auto and api.caller. supportsExportNamespaceFrom is true, Babel assumes that you have used a bundler that supports export * as ns, so Babel does not transform export * as ns, and the bundler will convert export * as ns as needed.
• In other cases, Babel will transform export * as ns.
  (See also Add export-namespace-from to preset-env #11849,

  babel/packages/babel-preset-env/src/index.js

  Lines 281 to 288 in 45fdb87

  	const shouldSkipExportNamespaceFrom =
  	(modules === "auto" && api.caller?.(supportsExportNamespaceFrom)) ||
  	(modules === false &&
  	!isRequired("proposal-export-namespace-from", transformTargets, {
  	compatData,
  	includes: include.plugins,
  	excludes: exclude.plugins,
  	}));

  )

When we say @babel/preset-env enabled some features by default: we mean users don't need extra config, and preset-env will activate the plugins when it is necessary. This is what env means in preset-env: It is a collection of Babel plugins and more importantly, it tries to ship the minimal required plugins for your app/website, based on targets and other environment information.

May i think the above shouldTransformExportNamespaceFrom is just to compatible with caller syntax in the near future? And, if caller been supported, does the preset-env include @babel/plugin-proposal-export-namespace-from by default ? (Or the default includes mean is use the default config as premise(work by babel-loader and @rollup/plugin-babel))

The options.caller is used to overwrite api.caller when babel-loader or generally a babel caller does not specify its caller supports. The api.caller is well maintained (babel-loader, @rollup/plugin-babel) and thus I don't recommend to overwrite api.caller. In fact, when api.caller does not have support data, it will enable the transform unconditionally.

[monic-shixi]

yep, so the includes default was with some premise.
And if the shouldTransformExportNamespaceFrom is false, It will enable the syntax-export-namespace-from.
The syntax-export-namespace-from blog said is just to enable babel parse this syntax.
And the main code is just add exportDefaultFrom to plugins:

manipulateOptions(opts, parserOpts) {
      parserOpts.plugins.push("exportDefaultFrom");
    },

It will transform to proposal-export-default-from by babel-core ?

[JLHwung]

The syntax-export-namespace-from is a syntax switch to allow @babel/parser to parse so it will not throw for export * as ns. This is important because export * as ns is recently added to the spec and @babel/parser has supported it for a while: Any staging ECMAScript features will be behind a parser plugin.

And the main code is just add exportDefaultFrom to plugins:

exportDefaultFrom and exportNamespaceFrom are different plugins. I assume you mean exportNamespaceFrom.

It will transform to proposal-export-default-from by babel-core ?

No, the missingPlugins.js is used to offer a friendly message to users: Hey I have seen export * as ns usage in your code, which should be parsed if you have enabled exportNamespaceFrom but you didn't. Do you forgot to add @babel/proposal-export-namespace-from?

[monic-shixi]

Thanks ❤️
I also see bugfixes and shippedProposals options config.
From blogs can known, the shippedProposals is enable parser syntax plugin instead of transfrom if browsers support.
The bugfixes option is enable @babel/preset-modules to compiled broken syntax to supported syntax.
By read code, where different from this?
If bugfixes is true, it juest add some plugins(from preset-modules), but the pluginsList is still be added:
https://github.com/babel/babel/blob/master/packages/babel-preset-env/src/index.js#L44-L66

const pluginLists = {
  withProposals: {
    withoutBugfixes: pluginsList,
    withBugfixes: Object.assign({}, pluginsList, pluginsBugfixesList),
  },
  withoutProposals: {
    withoutBugfixes: filterStageFromList(pluginsList, proposalPlugins),
    withBugfixes: filterStageFromList(
      Object.assign({}, pluginsList, pluginsBugfixesList),
      proposalPlugins,
    ),
  },
};

function getPluginList(proposals: boolean, bugfixes: boolean) {
  if (proposals) {
    if (bugfixes) return pluginLists.withProposals.withBugfixes;
    else return pluginLists.withProposals.withoutBugfixes;
  } else {
    if (bugfixes) return pluginLists.withoutProposals.withBugfixes;
    else return pluginLists.withoutProposals.withoutBugfixes;
  }
}

So, i think if bugfixes is enabled, just extends the original(Object.assign({}, pluginsList, pluginsBugfixesList)). And if extends original, where broken syntax from?
Or the main code is in filter-items.js?

 for (const item in list) {
    if (isRequired(item, targets, options)) {
      result.add(item);
    } else if (pluginSyntaxMap) {
      const shippedProposalsSyntax = pluginSyntaxMap.get(item);

      if (shippedProposalsSyntax) {
        result.add(shippedProposalsSyntax);
      }
    }
  }
  //...
  return result;
}

if target supported, just add syntax from pluginSyntaxMap?

But i don't known what different after bugfixes enabled?

[monic-shixi]

removeUnnecessaryItems(pluginNames, overlappingPlugins);.

by removeUnnecessaryItems function, can i assuming that bugfixes work for target browsers is not required(filterItems'sisRequired) plugins(target supported), but the some feature syntax is not be supported, so add this bugfixes for this.

It's just be my assuming.