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 #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: JamesHenry/typescript-estree#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.

typescript-eslint/typescript-eslint#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.