Add support for customizing parser plugins

[g-plane]

Maybe partially fix #505 .

This PR enables a feature that user can enable or disable babel parser plugins via parserOptions in .eslintrc file. This can let us parse TypeScript code with babel.

If anyone can't wait this PR, you can try: https://github.com/g-plane/pluggable-babel-eslint

[sibelius]

can we use typescript plugin when the file has extensions .ts or .tsx
and use flow plugin when the file has extensions .js or .jsx

using the extensions approach you don't even need to add typescript as a parser option

we are migrating incrementally to typescript using this approach https://medium.com/entria/incremental-migration-to-typescript-on-a-flowtype-codebase-515f6490d92d

[nstepien]

@sibelius You can use overrides: https://eslint.org/docs/user-guide/configuring#disabling-rules-only-for-a-group-of-files
For example in my config file I currently have:

  overrides: [{
    files: ['*.ts', '*.tsx'],
    parser: 'typescript-eslint-parser',
    parserOptions: {
      sourceType: 'module'
    },
    rules: tsRules
  }, {
    files: ['*.tsx'],
    parserOptions: {
      ecmaFeatures: {
        jsx: true
      }
    }
  }, ...]

[g-plane]

@sibelius babel-eslint is just a parser and it isn't able to detect what the extension is.

[kaicataldo]

Just so you're aware, another approach to solve this problem was discussed here. The PR that I started (and unfortunately was unable to land at the time) is here.

I personally think that reading the Babel config is the right approach, because you then don't have to manage and keep in sync what is essentially two separate Babel configs.

I'm hoping to get back to my PR sometime, but I just haven't had the time unfortunately.

[g-plane]

So can this PR keep open?

[nstepien]

@hzoo @existentialism
Can we get this looked into? I'd love to use babel-eslint for ts files.

[sibelius]

@g-plane can you read babel config from file and use it in this PR?

[g-plane]

@sibelius Yeah I will try but not sure whether I can do it well or not.

[g-plane]

It's OK to support .babelrc, but it seems that it isn't easy to support babel.config.js.

[g-plane]

I don't add the feature that supports reading Babel config now, but I have made a file which may resolve the Babel config. Everyone can review that file first and comment here. Link: https://github.com/g-plane/pluggable-babel-eslint/blob/master/lib/config/project-wide.js

If the logic of that file has no problems, I will add it to babel-eslint itself later.

[kaicataldo]

@g-plane The original implementation that I was working on let babel itself do all the configuration resolution, which I thought was a good thing because it meant that the config resolution logic wouldn't have to be duplicated (easier to maintain, smaller surface area for bugs, etc.).

My work obviously fell by the wayside, and I'm unsure of how the Babel v7 config file changes affect the implementation I was working on. Do you feel like this shouldn't happen in Babel core? Thanks for looking at this!

[g-plane]

I don't think using "@babel/core" directly is a good idea, because it has some dependencies like "@babel/generator", which is unnecessary. However, I'm not opposed to create a new npm package that uses "@babel/core".

[skyrpex]

Is having unnecessary dependencies the only con about using @babel/core? I never take that very seriously since it doesn't affect in any way other than the total node_module size after install...

[hzoo]

because it has some dependencies like "@babel/generator", which is unnecessary

The reason why I would think this isn't an issue is because we made an assumption that if you are using babel-eslint you are using Babel, and thus already would have @babel/core and everything else as a dependency (we would make it a peerDep)

[g-plane]

Hmm...well, if @kaicataldo 's PR is merged, I will close this PR.

[kaicataldo]

@g-plane I'm taking some time off over the next month and will be able to work on this again. That being said, if someone beats me to it, they should feel free!

[kaicataldo]

#711 has landed

[hzoo]

Closing since ^ landed!

[hzoo]

Although if we want to support TS here, we may need some of the other code in this PR?

[kaicataldo]

Yeah, that's something that maybe should be coordinated with typescript-estree.