Feature: Enable syntax based on reading from `.babelrc`

[hzoo]

Ref #434 (subset of syntax), #523 (user plugins), #505 (Typescript)

babel-eslint/lib/parse.js

Lines 18 to 22 in bf27f60

	plugins: [
	"flow",
	"jsx",
	"estree",
	"asyncFunctions",

Instead of having to:

• add to the plugin list whenever there is a new syntax and release a new version
• using a wildcard/star * option (found out that was a bad idea due to breaking changes between plugins like decorators/decorators2 so wouldn't be able to easily resolve that)
• expose a user config whitelist

We should be able to just read from a user's Babel config. @babel/core should expose a way for another tool to get relevant information from a user's config file (like return the list of syntax plugins used). babel-eslint could try to read that and just populate the parser options and we can remove the defaults. I think it's safe to assume if you are using babel-eslint you are using babel, and should have a config (can wrap in try/catch or fallback to default list)?

• Less config (re-using config)
• Enable subset of features
• We should be able to remove all deps and just do a peerDep on @babel/core maybe? Then it would use the version of babel in your project rather than it's own dep. And maybe the same for the eslint deps?

babel-eslint/package.json

Lines 14 to 17 in bf27f60

	"@babel/code-frame": "7.0.0-beta.36",
	"@babel/traverse": "7.0.0-beta.36",
	"@babel/types": "7.0.0-beta.36",
	"babylon": "7.0.0-beta.36",

edit: I believe we are only using @babel/types to get the the VISITOR_KEYS, and traverse to do a fast transform of the AST

Thoughts? cc @ljharb @kaicataldo @loganfsmyth @azz @danez @zertosh

[azz]

Makes perfect sense to me. Much better long term solution and it's good for perf, too.

[kaicataldo]

I'd like to work on this.

[kaicataldo]

And agree, I think it should use the new @babel/core API and fallback to the default (potentially outdated) list when it isn't there.

[hzoo]

Awesome, looks like @loganfsmyth was thinking about the babel side in babel/babel#6332 (comment) (didn't realize we had a PR for getting parserOpts earlier)

[ljharb]

fwiw, once this is implemented, the airbnb eslint config can finally switch parsers to babel-eslint, since we’ll be able to get parsing errors on syntax we’re not transforming - this includes enabling async/await and class fields.

[ljharb]

As for a fallback, i would definitely want a parser option that caused the linting run to fail outright if there’s no babel config present.

[kaicataldo]

I have some time to work on this right now, but wanted to make sure we agreed on an API.

@loganfsmyth's suggestion of exposing a parsing method that would do config loading, parse, and return the AST seems like a good suggestion to me. This is similar to how typescript-eslint-parser uses typescript to generate the AST (defining it as a peer dep), converts the AST to ESTree, and passes it to ESLint.

Does this seem like a good way forward here?

cc @JamesHenry if you have any suggestions, having worked with what I believe to be a similar architecture for typescript-eslint-parser

[kaicataldo]

It looks like @xtuc is actually working on this, so I'll unassign myself.

[xtuc]

I had the intention to do so, but missing time unfortunately. Feel free to take it.

Don't hesitate to ping me tho.