-
-
Notifications
You must be signed in to change notification settings - Fork 239
Add support for customizing parser plugins #692
Conversation
can we use typescript plugin when the file has extensions .ts or .tsx 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 |
@sibelius You can use overrides: https://eslint.org/docs/user-guide/configuring#disabling-rules-only-for-a-group-of-files overrides: [{
files: ['*.ts', '*.tsx'],
parser: 'typescript-eslint-parser',
parserOptions: {
sourceType: 'module'
},
rules: tsRules
}, {
files: ['*.tsx'],
parserOptions: {
ecmaFeatures: {
jsx: true
}
}
}, ...] |
@sibelius |
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. |
So can this PR keep open? |
@hzoo @existentialism |
@g-plane can you read babel config from file and use it in this PR? |
@sibelius Yeah I will try but not sure whether I can do it well or not. |
It's OK to support |
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. |
@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! |
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". |
Is having unnecessary dependencies the only con about using |
The reason why I would think this isn't an issue is because we made an assumption that if you are using |
Hmm...well, if @kaicataldo 's PR is merged, I will close this PR. |
@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! |
#711 has landed |
Closing since ^ landed! |
Although if we want to support TS here, we may need some of the other code in this PR? |
Yeah, that's something that maybe should be coordinated with typescript-estree. |
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