Using { useBuiltIns: usage } causes circular dependencies

[timdp]

If I change my preset-env config from the default { useBuiltIns: false } to 'usage', I get tons of circular dependency warnings from Rollup, e.g.,

Circular dependency: ../../node_modules/core-js/modules/_export.js -> ../../node_modules/core-js/modules/es6.function.name.js -> ../../node_modules/core-js/modules/es6.regexp.match.js -> ../../node_modules/core-js/modules/es6.regexp.constructor.js -> ../../node_modules/core-js/modules/_inherit-if-required.js -> ../../node_modules/core-js/modules/_set-proto.js -> ../../node_modules/core-js/modules/es6.object.set-prototype-of.js -> ../../node_modules/core-js/modules/_export.js

And then my bundle crashes on this statement in core-js:

_export(_export.S, "Object", {
  setPrototypeOf: _setProto.set
});

where _export is undefined. So that looks a lot like the circular dependency hadn't been populated yet upon the call to it. If I comment out that statement, it just crashes on the next occurrence of _export.

The question is, of course, what causes the circular dependency to be introduced. One possibility is that the core-js code itself is getting run through Babel somehow.

I'm using the latest versions of node-resolve, commonjs, and babel (+ preset-env), in that order.

In #250, you recommend trying the beta version, but unfortunately, I get the same behavior with v4.1.0-0.

I realize this is not necessarily an issue with this plugin, but unfortunately, it's really hard for me to debug it outside of Rollup. Any input you might have is appreciated. Thanks!

[timdp]

I've created a minimal implementation. If I run yarn build there, I get:

(!) Circular dependency: node_modules/core-js/modules/es6.array.reduce-right.js -> node_modules/core-js/modules/es6.array.reduce-right.js
(!) Circular dependency: node_modules/core-js/modules/_export.js -> node_modules/core-js/modules/es6.function.name.js -> node_modules/core-js/modules/es6.regexp.match.js -> node_modules/core-js/modules/es6.regexp.constructor.js -> node_modules/core-js/modules/_inherit-if-required.js -> node_modules/core-js/modules/_set-proto.js -> node_modules/core-js/modules/es6.object.set-prototype-of.js -> node_modules/core-js/modules/_export.js
[more circular dependencies]

The build completes, but if I run it, I get the same error:

/home/tim/Code/rollup-plugin-babel-254-repro/dist/index.js:33
	_export(_export.S, 'Object', {
	                ^

TypeError: Cannot read property 'S' of undefined
    at /home/tim/Code/rollup-plugin-babel-254-repro/dist/index.js:33:18
    at Object.<anonymous> (/home/tim/Code/rollup-plugin-babel-254-repro/dist/index.js:767:2)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3

The problem does go away if I set targets to anything above >= 1% so one of the most legacy transforms must be failing.

[timdp]

Also, { babelrc: false } seems to make a big difference. I've pushed 2d885b6 which runs the plugin twice: once without options, taking the Babel config from package.json, and one with the config passed directly to the plugin. The former works, the latter fails.

[loganfsmyth]

The issue is that Babel configuration in a package.json file will only affect that single package, whereas configuration passed to babel(babelOptions) will affect all files in your package.

The job of useBuiltins: 'usage' is to insert references to core-js, and by running your configuration on files in node_modules, you run the risk of creating dependency cycles, because usage can actually insert a reference to core-js inside core-js, which is what you are seeing.

If you absolutely need to compile things in node_modules, I'd really recommend using a package whitelist, or at least explicitly excluding core-js and any other polyfill packages.

Compiling node_modules wasn't really common in the past, so we're still working out good workflows for doing it well without this risk.

[timdp]

Thanks! That makes sense. I did try excluding **/core-js/** earlier, which didn't seem to help, but maybe I did it wrong. I'll give it another try soon.

[timdp]

Confirming that { exclude: [/\/core-js\//] } fixes it. I'll close this issue.

Thanks for creating babel/babel#8754 as well. Very curious to see what the outcome of that will be.