Copied from #2844 (comment)
I feel like the parser option is a bit of a leaky abstraction. It would be nice if the option was called language or something like that so you can pass --language scss and we'd figure out which parser to use.
parser |
language |
| babylon |
javascript |
| flow |
flow |
typescript (actually typescript-eslint-parser) |
typescript |
| graphql |
graphql |
postcss css |
css |
postcss- scss |
scss |
postcss- less |
less |
| parse5 |
html |
json (actually babylon.parseExpression) |
json |
Unfortunately changing this would obviously be an API breaking change.
Posted by @lydell
I agree that the parser option is strange and could be better.
Btw, the postcss parts of your table should look more like this:
parser |
language |
| postcss (actually postcss-less+postcss-scss+postcss-media-query-parser+postcss-selector-parser+postcss-values-parser) |
css |
| postcss-scss (actually like css but minus postcss-less) |
scss |
| postcss-less (actually like css but minus postcss-scss) |
less |
We could introduce this option and deprecate the parser option.
I feel like the
parseroption is a bit of a leaky abstraction. It would be nice if the option was calledlanguageor something like that so you can pass--language scssand we'd figure out which parser to use.parserlanguagetypescript-eslint-parser)postcsscsspostcss-scsspostcss-lessbabylon.parseExpression)Unfortunately changing this would obviously be an API breaking change.
Posted by @lydell
We could introduce this option and deprecate the parser option.