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 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!