Babel-eslint: Possible to use `@babel/plugin-transform-typescript` with this?

[trusktr]

I'm wondering if I can use @babel/plugin-transform-typescript along with babel-eslint instead of typescript-eslint-parser.

[skyrpex]

I think this is related https://github.com/babel/babel-eslint/pull/692

[hzoo]

Not sure it will completely work yet but #711 helps this process and we may need another PR like #692 to finish it up

[kaicataldo]

Yeah, there might be some work needed to make sure the AST looks correct with types. I know that in the past @JamesHenry talked about wanting to make sure the ASTs produced by this and typescript-estree matched. Given that the TypeScript team is planning to contribute to ESLint to get the TS experience up to snuff, it would probably be a good idea so that any TypeScript plugins can be used with either.

[kaicataldo]

Relevant typescript-estree issue: https://github.com/JamesHenry/typescript-estree/issues/112

[JamesHenry]

The babel implementation may be an option for some folks. Part of the effort to align on ASTs is to facilitate that :)

However, I would note that you will miss out on a whole category of linting if you go with babel-eslint for TypeScript support, because the TypeScript compiler is not involved. This means you will not be able to use rules which rely on type information, which can be very useful.

So, yes, it definitely has its place and will be a lightweight solution for folks, depending on their use-cases

[JamesHenry]

Just to double down on it - multiple solutions using shared primitives is a great situation IMO (shared primitive here being the AST)

[JamesHenry]

ICYMI, announcement following on from what Kai mentions above: https://eslint.org/blog/2019/01/future-typescript-eslint

[iFwu]

ICYMI, announcement following on from what Kai mentions above: https://eslint.org/blog/2019/01/future-typescript-eslint

Thank you so much for your contribution! People were complaining about TSLint for a long time.

[wcandillon]

Yes that's incredible. Thank you so much. Here is my typescript with eslint setup: https://github.com/wcandillon/eslint-config-react-native-wcandillon
You can take inspiration from it.

It's amazing to see how things evolve and how fast they evolve.

[chengjianhua]

@JamesHenry @kaicataldo

If I don't get it wrong, the new approach typescript-eslint which eslint support typescript still need a specific parser @typescript-eslint/parser for eslint configuration.

If that's it, I'm afraid of that we can't lint .ts files and .js files through a universal eslint configuration. It's impossible for us to specify different parser for different files right now, right?

[chengjianhua]

Use babel-eslint as the only parser is the best ways to use eslint from the viewpoint of a user.

In the view of users, we don't care about how eslint deal with it. We just know that babel supports parsing .ts files and babel-eslint supports babel, so babel-eslint supports .ts files if we enabled @babel/plugin-typescript.

TypeScript support to be able to be parsed by babel is the great success in the stand of users, and I can't take that I need to change my eslint configuration a lot and not be able to lint .js and .ts at the same time. If we are migrating my codes from flow or es to typescript in a progressive way, we need this feature.

[kaicataldo]

@chengjianhua It actually is possible to specify different parsers for different extensions in ESLint using glob-based configuration.

And just to be clear, neither @JamesHenry or myself has suggested that babel-eslint shouldn't support TS. PRs are definitely welcome!

[krousseau-cs]

Based on the response I received in the typescript-eslint/parser repo regarding support for babel proposal plugins, it seems like babel-loader support (or at least not blowing up) w/ typescript is the only option forward. They have no plans to support proposals.

https://github.com/typescript-eslint/typescript-eslint/issues/136

[JamesHenry]

Until last year, the TypeScript compiler was the way that TypeScript source code was parsed.

Now there are two ways:

• The TypeScript compiler
• @babel/parser

This is a fork in the road when it comes to parsing.

• typescript-eslint is a solution built on top of the TypeScript compiler "path"
• babel-eslint is a solution built on top of the babel "path"

It is great that we have more than one solution - but it is not possible to mix and match the parsing option from one and linting option from another right now (nor is there anything planned).

Please note, the TypeScript compiler is still the only way to type check your code. Babel parses and strips the type information, you still need the TypeScript compiler running if you want type checking.

[JamesHenry]

@chengjianhua As Kai explains, you are not correct. As of right now, the typescript-eslint codebase itself is a mixed JS and TS project, for example. It is very much possible for ESLint to be configured to use different parsers for different file types.

[krousseau-cs]

@JamesHenry that makes sense. If I want to keep in babel land but still add typescript types on top of it can I use babel-eslint w/ typescript-eslint/plugin?

[JamesHenry]

That's exactly what this issue is open for :)

I'm personally not sure if there are any blockers right now, so I can't comment either way. My focus has been on typescript-eslint recently, I hope to contribute to babel-eslint more again in the future

[kaicataldo]

I'm not aware of any blockers for adding support for TypeScript, now that babel-eslint is reading the end user's Babel config file prior to parsing.

One thing this project needs to decide is if it's planning to track and match the shape of the AST generated by @typescript-eslint/parser or not. The obvious benefit of doing this is that this parser could be compatible with the rules in@typescript-eslint/eslint-plugin (though this may not be the case if a rule relies on some extra functionality provided by the TypeScript compiler).

Note that babel-eslint will never be able to provide any of the extra functionality that the actual TypeScript compiler will be able to provide, and so this project will not be able to reach feature parity with @typescript-eslint/parser.

[krousseau-cs]

Is there any way to run the typescript compiler and use babel proposals? It works w/ eslint when using babel-eslint but I still haven't found a way to run tsc when using proposals that aren't supported by typescript such as null coallescing or optional chaining.

[chengjianhua]

@JamesHenry Thanks~ I'm glad to see that I was wrong. If it's able to configure different parsers for various extensions, it eliminated my doubts basically.

babel-eslint is not going to reach feature parity with @typescript-eslint/parser makes sense, if there is no plan to track and match the shape of the AST generated by @typescript-eslint/parser, how can we lint typescript with babel-eslint? Is there a guide for this?

[armano2]

at @typescript-eslint we are doing alignment tests of AST generated by babel ast-alignment, you can find required plugins to produce correct AST in here parseWithBabelParser

We are also tracking difference between generated output fixtures-to-test, and reporting issues if we find some.

there is few major differences in generated AST babel with estree vs typescript-eslint.

• jsx (ranges are not same, as far as i know there is fix for that here)
• template literals (ranges are not same, as far as i know there is fix for that here)
• optional/abstract methods

and few nodes needs postprocessing to match AST generated by @typescript-eslint:
preprocessBabylonAST

• StringLiteral
• NumericLiteral
• BooleanLiteral
• TSCallSignatureDeclaration
• TSConstructSignatureDeclaration
• TSFunctionType
• TSConstructorType
• TSMethodSignature
• TSTypeParameter
• ClassProperty
• TSExpressionWithTypeArguments

---

you can also check "big" alignment test project typescript-estree-test, i'm going to extend tests to cover babel-eslint when its going to support typescript

[PutziSan]

Hi,
I'm not sure if I understood everything, but I think at the moment the only way to use ESLint with a mixed JS/TS codebase is with this config:

module.exports = {
  parser: "babel-eslint",
  overrides: [
    {
      files: ["**/*.ts", "**/*.tsx"],
      parser: "@typescript-eslint/parser",
      plugins: ["@typescript-eslint"],
      // If adding a typescript-eslint version of an existing ESLint rule,
      // make sure to disable the ESLint rule here.
      rules: {/*...*/}
    }
  ],
};

Is this the (currently) correct way? Is it planned in the future that we can only use babel-eslint for both?

[diegoddox]

@PutziSan did work for you? I'm trying the same setup but is not working for me

[PutziSan]

I work almost exclusively with TypeScript now and don't use eslint at the moment.
The eslint config of create-react-app by facebook seems to follow this approach as well and considering the popularity of this project I can imagine that it works.

[kaicataldo]

Thank you for the issue. Now that @babel/eslint-parser has been released, we are making this repository read-only. If this is a change you would still like to advocate for, please reopen this in the babel/babel monorepo.