babel-utils/babel-plugin-tester

Setting babelrc to true isn't picking up .babelrc

bbohen opened this issue ยท 9 comments

I'm having an issue when doing:

babelOptions: {
    // doesn't work
    babelrc: true
},

This results in an unexpected token error as my test is attempting to parse code that requires multiple babel presets to parse (its a react component). This can easily be fixed by supplying the presets directly in the test config, or by adding the extends option like so:

babelOptions: {
    // this works
    presets: ["es2015", "stage-0", "react"],
    // this works too
    extends: path.resolve(__dirname, '..', '.babelrc'),
},

I'm wondering if I'm missing something here in regards to preferred approach when using a .babelrc? Looking through the code I don't see any logic around the babelrc boolean so I am unsure as to the desired experience here.

I would be happy to PR a fix if this indeed a bug, or update the documentation if I'm just missing something here. Thanks for this tool, it's super useful ๐Ÿ‘

Thanks for this tool, it's super useful ๐Ÿ‘

I'm glad you think so!

Looking through the code I don't see any logic around the babelrc boolean so I am unsure as to the desired experience here.

Correct, this just gets forward to babel.transform. So I'm unsure of what's going on here. If you want to add a console.log to make sure it's forwarding properly that'd be cool..... oh wait!

I just realized what's going on. I'm pretty sure that babel needs to know the filename to be able to resolve the babelrc. So we need to provide the filename as well. I'm unsure whether we could accomplish that from our perspective inside the tool, you may just have to do:

babelOptions: {
  babelrc: true,
  filename: __filename,
}

I think that should work. If it does, could you add a note in the documentation about this? Probably a pretty common error...

Actually, it may be a good idea to add an invariant if you specify babelrc: true and don't specify a filename. Could you Make a Pull Request for that?

Thanks for the response and absolutely! I'll get on that tonight.

I'm actually going to add a filepath property in part to support changes I'm making here. That'll have an impact here. The filepath in the babelOptions will default to the filepath provided for every test. I'll hopefully have this done soon. I'll let you know.

Sounds good, if the .babelrc relative to that filepath can be resolved into a filename for babel that would fix this issue. Throwing an invariant could still be an option but there might need to be a bit more logic involved as the existence of presets or plugins would make a .babelrc unnecessary even if the user has specified babelrc: true.

Let's see how the dust settles as @thejameskyle and I are both actively working on this package right now.

Quick question if you're around...

pluginTester({
  filename: __filename,
  tests: [
    {
      filename: '/some/path',
      // ...etc
    },
    {
      // should the filename here be derived from the filename of the root-level config?
      // or should it just be undefined as it currently is?
      code: 'blah',
    }
  ]
})

Note that if we do assume the filename is based on the root-level config, then you could unset that by doing: filename: null for any of the tests. I think this is the least surprising API so that's what I'm going to go with unless I hear from you :)

I think that will work fine, if it helps at all here is how I ended up using it.

I decided that doing all that filename business was adding too much complexity and opted for the simpler solution. I added an example for it which I hope is helpful!