[Feature Request] Allow specifying parser per file extension

[weikinhuang]

Tell us about your environment

• ESLint Version: ^3.x.x
• Node Version: latest
• npm Version: latest

What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint & typescript-eslint

Proposal
It would be beneficial to include the ability for eslint to determine which parser to use based on file extension so that eslint can be run against a multi-language codebase in a single pass. By extension this would also benefit text editors that can't currently specify multiple configs so that a single config can be used to check the entire project.

Right now, I am running eslint once for JS(X), and again for Typescript each using a different parser since the ts-parser doesn't support most stage-X ecma features and the babel-parser doesn't support TS syntax.

[kaicataldo]

This does seem useful to me now that we're actively supporting more parsers (TypeScript, Babel, and now Vue!).

One idea: the parser option could accept an object that maps the parser to a filetype and its parser options:

{
  "parser": {
    "typescript-eslint-parser": {
      "filetypes": [".ts"],
      "parserOptions": {}
    },
    "vue-eslint-parser": {
      "filetypes": [".vue", ".js"],
      "parserOptions": {}
    }
  }
}

Curious what other team members think!

[platinumazure]

@kaicataldo What happens if multiple parsers are listed as supporting the same file type(s)?

[kaicataldo]

What do you think the most expected behavior would be? Seems to me like it should throw an error.

[platinumazure]

Right, I was thinking that too but then I wondered about going by extension... and then I realized maybe this could be covered by glob based configuration. What do you think of that?

…

On May 4, 2017 5:40 PM, "Kai Cataldo" ***@***.***> wrote: What would be the most expected behavior? Seems to me like it should throw an error. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8543 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARWeqO8QJRw0FSgj2umDb2yO-QgD_Sbks5r2lPDgaJpZM4NRMyy> .

[kaicataldo]

@platinumazure To be honest, I don't quite know what means! Mind sharing some examples?

[platinumazure]

@kaicataldo Sorry, see #3611. Basically #3611 feels like a generalization of my file-extension-based proposal.

Example of what I meant for parsers:

"parser": {
    "js": {
        "parser": "espree",
        "parserOptions": {}
    },
    "ts": {
        "parser": "typescript-eslint-parser",
        "parserOptions": {}
    }
}

Where that proposal falls apart is if you have multiple file types that need the same parser. Then a glob-based config approach might work better since you just specify config overrides for uncommon cases:

{
    "parser": "espree",
    "parserOptions": {},
    "overrides": {
        "*.ts": {
            "parser": "typescript-eslint-parser",
            // For this example we'll assume no parserOptions need to change
            "rules": {} // Override rules as well for TS files. Basically any config option can be modified here
        }
    }
}

But I'm not 100% sure what the glob-based config proposal actually looks like.

[mightyiam]

I have just released a package that should provide this feature. Please try! Bug reports, feature requests and pull requests are warmly welcomed!
https://www.npmjs.com/package/eslint-multiple-parsers

[kaicataldo]

I believe this is now supported with glob configuration!

[mightyiam]

Great. Now I know how to deprecate an npm package.