Babel config cached incorrectly, throwing duplicate plugin error

[sholladay]

Description

Babel configuration is misbehaving, throwing an error on startup before any tests are run.

My team has been using the configuration below with AVA 1.0.0-beta.4 for a while without trouble. However, it breaks on 1.0.0-beta.5. This seems to be a regression where the Babel configuration is somehow processed or cached incorrectly.

There is one super weird part about this bug. If I remove babel.plugins from package.json, then run AVA, then put the plugins back and run AVA again, it somehow makes things work (no error is thrown and tests run as expected). Running npx ava --reset-cache and then running AVA again causes the issue to reappear. So this really appears to be cache related, albeit it's broken when there is no cache.

Test Source

Anything.

Error Message & Stack Trace

✖ Internal error
  Error: Duplicate plugin/preset detected.
  Error: Duplicate plugin/preset detected.
  If you'd like to use two separate instances of a plugin,
  they need separate names, e.g.

    plugins: [
      ['some-plugin', {}],
      ['some-plugin', {}, 'some unique name'],
    ]
      at assertNoDuplicates (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-descriptors.js:165:13)
      at createDescriptors (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-descriptors.js:74:3)
      at createPluginDescriptors (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-descriptors.js:65:10)
      at alias (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-descriptors.js:57:49)
      at cachedFunction (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/caching.js:32:19)
      at plugins.plugins (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-descriptors.js:24:77)
      at mergeChainOpts (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-chain.js:303:26)
      at /Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-chain.js:267:7
      at buildRootChain (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/config-chain.js:64:29)
      at loadPrivatePartialConfig (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/partial.js:55:55)
      at loadFullConfig (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/full.js:43:39)
      at Object.loadOptions (/Users/sholladay/Code/my-company/client/node_modules/@babel/core/lib/config/index.js:27:36)
      at loadOptions (/Users/sholladay/Code/my-company/client/node_modules/ava/lib/babel-pipeline.js:178:16)
      at Object.filename [as precompileFull] (/Users/sholladay/Code/my-company/client/node_modules/ava/lib/babel-pipeline.js:193:19)
      at map.reduce (/Users/sholladay/Code/my-company/client/node_modules/ava/api.js:145:28)
      at Array.reduce (<anonymous>)
  From previous event:
      at emittedRun.then.then.precompilation (/Users/sholladay/Code/my-company/client/node_modules/ava/api.js:137:27)

Config

{
    "ava": {
        "require": [
            "@babel/register"
        ]
    },
    "babel": {
        "presets": [
            "@babel/preset-react"
        ],
        "plugins": [
            "@babel/plugin-transform-modules-commonjs",
            "@babel/plugin-syntax-object-rest-spread"
        ]
    }
}

Command-Line Arguments

ava

Relevant Links

Possibly related to #1817.

Environment

Node.js v10.1.0
darwin 17.5.0
ava 1.0.0-beta.5.1
npm 6.0.1

[novemberborn]

Looks like a Babel compilation issue. We cache the results, and do little invalidation at the moment (the "babel" options in package.json are ignored for cache invalidation), which is probably why it got confusing with --reset-cache.

Is there any more detail about which plugin is the duplicate?

What happens if you remove just "@babel/plugin-syntax-object-rest-spread"? AVA adds that one directly but it's supposed to check if it's already used.

[sholladay]

Tried a bunch of things, but today I cannot reproduce this any more. I checked both beta 5 and 6. Best guess is it was a bug in a subdependency that got fixed (probably in Babel itself). Wish I had more details... 😄

[sholladay]

Hmm this started happening again for me as of beta 7. It's reliable, I can switch between beta 6 and 7 with a nuke rm -rf ~/.npm package-lock.json node_modules in between and beta 7 does it, but not 6.

Same cryptic message. It doesn't show which plugins or presets are duplicated. And touching package.json still matters. Basically, it always fails the first time, then I have to modify package.json, then I have to run AVA again and let it fail, then put package.json back the way it was originally, run AVA again and finally it will pass.

I have been trying to isolate if specific parts of package.json are important and I think it is @babel/plugin-syntax-object-rest-spread. If I only remove @babel/plugin-transform-modules-commonjs before the second run, then the third run seems to always fail the same as the first.

BTW are you sure the below statement is true?

... "@babel/plugin-syntax-object-rest-spread"? AVA adds that one directly but it's supposed to check if it's already used

When I remove @babel/plugin-syntax-object-rest-spread and run AVA (any version, any number of times), I get:

  SyntaxError: /Users/sholladay/Code/noirdoor/client/test/albums/reducers.js: Support for the experimental syntax 'objectRestSpread'isn't currently enabled (31:27):

  _class.raise (node_modules/@babel/parser/lib/index.js:3906:15)
  _class.expectPlugin (node_modules/@babel/parser/lib/index.js:5240:18)
  _class.parseObj (node_modules/@babel/parser/lib/index.js:6649:14)
  _class.parseExprAtom (node_modules/@babel/parser/lib/index.js:6281:21)
  _class.parseExprAtom (node_modules/@babel/parser/lib/index.js:3607:52)
  _class.parseExprSubscripts (node_modules/@babel/parser/lib/index.js:5911:21)
  _class.parseMaybeUnary (node_modules/@babel/parser/lib/index.js:5890:21)
  _class.parseExprOps (node_modules/@babel/parser/lib/index.js:5799:21)
  _class.parseMaybeConditional (node_modules/@babel/parser/lib/index.js:5771:21)
  _class.parseMaybeAssign (node_modules/@babel/parser/lib/index.js:5718:21)

However, on the buggy versions of AVA (e.g. beta 7), if I then add the plugin back to my config after letting it fail once, then it will pass.

[novemberborn]

@sholladay are you using RC1 releases for your Babel plugins?

[sholladay]

I am, yes. I'm not seeing any peerdependency warnings related to Babel, but downgrading to 7.0.0-beta.51 seems to fix it. Guess it's my fault, then? Will close since I have a solution. Thanks! ❤️

[novemberborn]

@sholladay I'd like to get to the bottom of this actually. Downgrading the version just means there's two different plugins being used, so Babel doesn't complain… but once they release their stable version npm's dependency deduping will make the plugins be the same again.

If you could reproduce this setup outside your codebase that'd make it a bit easier for me to figure out the problem. I suspect it may be because we install that syntax plugin ourselves. We should be detecting it's already there, but maybe there's another way to install it where it doesn't trip up Babel.

[sholladay]

Okay here's your minimal repro!

1. Init a project with AVA and Babel:

   mkdir /tmp/repro-ava-1828
   cd /tmp/repro-ava-1828
   npm init -y
   npm install --save-dev --save-exact \
       ava@1.0.0-beta.7 \
       @babel/plugin-syntax-object-rest-spread@7.0.0-rc.1

2. Add some Babel config to package.json

   "babel": {
       "plugins": [
           "@babel/plugin-syntax-object-rest-spread"
       ]
   }

3. Add a simple test so AVA is willing to run

   import test from 'ava';
   
   test('true is true', () => {
       t.true(true);
   });

4. Run AVA

   npx ava

The result, for me, is the same stack trace as I originally posted. I'm currently on Node 8.11.3 and npm 6.3.0, but that doesn't seem to matter in this case.

I used --save-exact in the example above in the hopes that the steps will remain reproducible in the face of new releases. But it's not what I was doing in practice, so it is not directly relevant.

[novemberborn]

Thanks @sholladay. Should be fixed with #1912.