Use @babel/core#parse

[kaicataldo]

refs #573

This PR updates babel-eslint to require @babel/core as a peer dependency and to use the user's Babel configuration when parsing files for ESLint. Up until now, babel-eslint has manually enabled all plugins (with the list falling out of date frequently). It also meant that babel-eslint could parse syntax that a configured instance of Babel itself didn't allow at compile time.

This change makes it so that the same Babel configuration is used for the parser both for linting and for compilation, and should eliminate a whole class of bugs as well as give the end user more fine-grained control over what the parser can and cannot parse.

Note that this is a breaking change, as using babel-eslint will now require @babel/core@>=7.2.0 and a valid Babel configuration file to run (see #711 (comment) for some discussion around this).

[kaicataldo]

For anyone coming across this - I'm just waiting for babel/babel#8986 to be merged and released to finish this up.

[sibelius]

@kaicataldo it is merged 💯

[tomwidmer]

@sibelius @kaicataldo And it is released https://github.com/babel/babel/releases/tag/v7.2.0 👍

[kaicataldo]

Planning to pick this up again this week. Here's an interesting edge case that I don't think was considered with this change: eslint/eslint#11189 (comment). Thoughts?

[ljharb]

I don’t think it’s reasonable to be concerned with a flagged, experimental feature in node that is still highly subject to a lot of change; nor do i think babel-eslint needs to be concerned with non-babel-users.

[kentcdodds]

I agree with @ljharb here 👍

[kentcdodds]

I can't tell from the PR. Is there a way to configure the location of the babel configuration as one of the parserOptions or something? With a toolkit (where the configuration does not necessarily live at the root of the project) being able to specify configuration directly would be really helpful.

[kaicataldo]

@kentcdodds This was discussed elsewhere (trying to find it and am failing - might've been on Slack 😅) and I hadn't gotten around to it yet. Added here. This was also useful for testing!

[kaicataldo]

This is ready for review/discussion. I'd love to figure out how to make these tests easier to manage, but I think the implementation here is reasonable and we can iterate in the future. Let me know how you feel.

Would also love to get the team's feelings about throwing when the required version of @babel/core isn't found. Also, am I missing anything configuration-wise? I know a lot changed in babel@7 and I'm still not super familiar with all the options surrounding configs, particularly in monorepos.

Edit: This actually isn't quite working, but I'd still love some eyes on the general approach here to see what people think. Thanks!

Edit: Looks like it's working now. I was missing passing through the filename that's now required since babel.config.js allows for overrides.

[kaicataldo]

Great! Will make some issues for us to discuss. Thanks for the input, everyone - it's been super helpful 👍

[kentcdodds]

Woo! Thanks!

[kaicataldo]

Issue to discuss how to handle missing config files here: #738

I'm not going to make an issue for my first question because I now think the current behavior is the best way to go. Feel free to comment if you disagree though.

[arahansen]

The README changes added here implies this change has already been released (or that is me optimistically reading into the description). Are these changes published anywhere?

[kaicataldo]

It hasn't been released yet. We just decided on a path forward for this last issue today and, pending landing that, we should be able to get a release out!

[hzoo]

Published these changes as [email protected] in the next tag for now and we will publish as 11.0.0 if we don't have any other issues

[the-spyke]

What if I have no .babelrc, but a custom preset? I remember asking about config file (#563), but time flies and approaches evolved since.

[kaicataldo]

@the-spyke Hey, not sure I understand - how would you be using a custom preset without a .babelrc file?

[the-spyke]

@kaicataldo Often you manually pass options to babel-loader. For example as in create-react-app scripts

[hadnet]

Published these changes as [email protected] in the next tag for now and we will publish as 11.0.0 if we don't have any other issues

When using [email protected] I got this error -> Parsing error: params is not iterable

[kaicataldo]

@hadnet Please create a new issue. Thanks!

[hadnet]

@kaicataldo I think somebody already did it (#749)

[jharris4]

Hi, I'm late to the party here, but we have a setup where we have tools that read our babel config from a custom file which is outside of the babel config file process, kind of akin to a custom preset as mentioned by @the-spyke.

Could we please add support in version 11.x to allow babelOptions that look something like this:

options.babelOptions = {
  presets: [ /* presets go here */ ],
  plugins: [ /* plugins go here */ ]
}

If I'm not mistaken, this should be a fairly simple change to make and I'd be willing to attempt a PR.

This would still allow the babel config to be custom specified, but just takes away the requirement that a babel config file has to exist in a specific location/format.

[JounQin]

When will it be released as stable???