Document the tradeoffs for this approach

[alexeagle]

Awkward issue - but having worked on TSLint lately and wiring it into our toolchain (and we'll start adding angular2 template support soon, + @mgechev ) - I'm curious why you'd want to lint a down-transpiled version of the code. You lose type information of course, plus all the ES7+ features (Esp. decorators) are de-sugared so they're harder to comprehend and analyze.

But I imagine you have a good reason to do this. Too much work to re-implement the checks in TSLint? I imagine adding some utilities to make it much easier to express a certain predicate about an AST subtree...

[JamesHenry]

Thanks for checking out the project @alexeagle! I am not sure I understand you correctly when you say "I'm curious why you'd want to lint a down-transpiled version of the code".

This project parses the source using the TypeScript compiler to produce a standard TypeScript AST, and then simply converts that AST into a form which matches the ESTree spec (evolving over at https://github.com/ESTree/estree).

This allows ESLint to interpret the AST and means we can take advantage of its (awesome) existing infrastructure, which includes a solid auto-fixing story, plugins and, of course, rules.

Now that the foundations of this parser are in, we are beginning to capture more and more type information and this will continue to evolve into custom rules based on it.

[JamesHenry]

PS. I am already using this parser on my large Angular 1 app, which is written in TypeScript, using decorators from a project I contribute to called ng-metadata

I am one of a whole generation of Angular 1 developers who are long time ESLint users. One of the reasons I am so passionate about this project is because I do not believe changing linter (and moving away from the amazing ESLint) should be part of a decision to migrate from Angular 1 to Angular 2.

[JamesHenry]

PPS @mgechev's work on linting against the style-guide has been fantastic, and I definitely believe it will be possible to match those capabilities through custom rules in ESLint + typescript-eslint-parser

[nzakas]

@alexeagle I think that @JamesHenry hit the nail precisely. One of the things we've heard repeatedly from ESLint users is that they are upset that moving to TypeScript means leaving ESLint behind. We've also heard that they wish TSLint was more like ESLint. There's no good reason that ESLint can't support TypeScript, all that was missing was a parser.

Take the case of another type dialect, Flow. Flow developers use ESLint directly with either Babel or the Flow parser, and with packages like eslint-plugin-flow that are specifically designed for that dialect. This was enabled because Babel and Flow support an ESTree format output. If ESLint is a good tool for working with Flow, there's no good reason why ESLint can't be a good tool for working with TypeScript.

[alexeagle]

I see, thanks for clarifying.

But, you still won't have a type checker available to ESLint. We have started writing TSLint checks that are type-aware, for example checking the types of the two operands to + among many others. Would you expect this sort of rule would eventually be possible in ESLint as well?

[JamesHenry]

Please could you point us to a specific example of what you mean?

[alexeagle]

Check out this test:
https://github.com/palantir/tslint/blob/master/test/rules/restrict-plus-operands/test.ts.lint

TSLint can warn if you add a string and a number, or a string and null, based on the type of the two operands. You can't do this kind of check syntactically.

To make this possible, we added an input to TSLint that points to a tsconfig.json or a ts.Program so we get access to the ts.TypeChecker provided by typescript's language services:
https://github.com/palantir/tslint#type-checking

[JamesHenry]

Thanks, that is clear and an interesting case. I will defer to @nzakas on this one as it relates directly to ESLint and rule config 😄

All the pieces are there, and it would be awesome if we could bring them together without needing big changes to ESLint

[JamesHenry]

I feel like the ESLint plugin could potentially do this (for example, we have literally just started one here https://github.com/nzakas/eslint-plugin-typescript).

It could look up the project's tsconfig.json in the same way that TSLint does to make a ts.TypeChecker (in some form) available to all its rules' create methods via a simple closure...

http://eslint.org/docs/developer-guide/working-with-rules

Perhaps we may need to keep a reference to the original TSNode in final output to prevent reimplementing a bunch of logic though...

[JamesHenry]

So... yeah, that works 🎉

[JamesHenry]

I have obviously hacked this together in a matter of minutes so it won't be a bullet-proof approach. In order to benefit from all of the existing TypeChecker methods I simply modded the parser to keep a reference to the original TSNode.

@nzakas How do you feel about that as a way of enabling these kinds of checks?

The great thing is that this does not require any changes to ESLint or how rules are configured. Everything is encapsulated in the parser and plugin.

ESLint Rule code (pretty much taken from @alexeagle's code in TSLint):

Created TS program for access to TypeChecker like so:

It's 00:16 here so officially signing off!

[nzakas]

We could do that, though I'd want to tweak the implementation a bit.

@alexeagle I think the overall point here is that ESLint is a lot more flexible than it may seem at first. Im willing to bet that ESLint can do anything TSLint can do or wants to do if we really focus on it.

[alexeagle]

@nzakas that's great, thank you for explaining. My remaining concern is just about fragmentation. Since there is no common API for writing a check/rule among the various tools, they don't have feature parity, and there are many editors to wire up, we risk having no tool that includes all the checks and works in all the editors. This leaves teams to use multiple tools and forgo good tooling support. ESLint is likely the best supported among editors (is this true?) so do we expect there will be enough effort to port remaining rules and features?

To make this a bit more concrete, we are working on the TS extensibility-model branch to add support for Angular 2 templates to the language service. This means you could ask for completions inside an Angular expression in a .html file, for example. But it also means we can write lint checks that detect style or correctness violations in templates, or in code that spans TS/html boundary. We will have to pick just one tool to build this support on. So far @mgechev has been the furthest on this track with his codelyzer tool, which was forked from TSLint.

So Angular team has some interest in implementing our stuff in the right tool, rather than having to do it N times.

[corbinu]

Just a comment that I am currently switching a large ES6 codebase to Typescript and lack of rules in TSlint has been an issue. We have a rather large eslint config and maybe a 2/3rds of the rules were available in TSLint even when using https://www.npmjs.com/package/tslint-eslint-rules

The bigger issue to me though is the lack of ability to use eslint plugins of which there are many more for example we use https://github.com/wix/eslint-plugin-lodash

So I am really excited at this approach. Thanks for all the hard work!