Lint Programs as a Whole

[jkillian]

Right now, TSLint lints files individually. This means that any information in one file (such as type information) is not available while linting other files.

One possible alternative is to, at startup, create a language services instance that has the source for the entire program and pass this to the rules. Full program information could then be used by the rules.

[ashwinr]

what additional features does this enable? we're not linting types yet anyway.

[jkillian]

Possibly stuff like this: #577

[adidahiya]

basically any rule that needs to inspect types will need all the type information from the compilation path in order to work reliably

[dallonf]

It'd at least be nice to pass a glob to tslint and lint multiple files.

[jkillian]

@dallonf When using it programmatically I assume? (Since obviously a glob will work when using it via the CLI)

[dallonf]

@jkillian I didn't know that was supposed to work ;) Created a ticket for my seperate issue: #688

[myitcv]

Picking up @aleksey-bykov's comment, I wonder if we can kick start some sort of effort on this.... We have a long list of rules that we want to write (let's ignore the fact many of these rules should in fact be part of TypeScript core)

@adidahiya @jkillian - are you aware of anyone who has tried to progress this?

As @Aleksey-Bykov points out, the effort involve in creating a custom linter that does have type information is not hard. The more complicated bit will be working out how to integrate this into tslint

[jkillian]

Sorry for the delayed response here @myitcv. I'm not aware of any progress on this so far, feel free to go for it if you have the time! I'm happy to discuss how we can integrate this kind of thing into TSLint as it is now

[alexeagle]

How will this approach match the compiler options of tsc with those passed to tslint?

For example, we need the same input files, same typings, same moduleResolution flag, same baseUrl,rootDirs (microsoft/TypeScript#5039), --skipDefaultLibCheck and so on. Otherwise the typecheck will fail when tslint runs, and the user has to carefully duplicate these settings.

One option is to read tsconfig.json as an input to tslint, but some users may have configuration in another place (we often wrap the compiler API to workaround differences in filesystem layout).

Another option is to work with the typescript team to run additional static analysis checks in the compiler itself, using some extensibility mechanism.

[myitcv]

@alexeagle - the approach we are following with tsvet is to reference the same tsconfig.json that is referenced by tsc.

As it stands, we only run tsvet once a compilation via tsc has succeeded. This obviates the need to ignore/dedup the compilation errors during the tsvet run.

Ultimately we could do away with the tsc step entirely and output compilation errors and our own custom errors in the tsvet step. This would need tsvet support for --watch and friends to become a reality practically speaking.

[alexeagle]

If the user will run a single program to type-check, run diagnostics,
produce custom errors, and emit, why not have tsc be that single program?
It seems simpler than replacing it by a different end-user application that
behaves the same as tsc.

On Wed, Mar 30, 2016 at 11:13 AM Paul Jolly [email protected]
wrote:

@alexeagle https://github.com/alexeagle - the approach we are following
with tsvet
#1048 (comment)
is to reference the same tsconfig.json that is referenced by tsc.

As it stands, we only run tsvet once a compilation via tsc has succeeded.
This obviates the need to ignore/dedup the compilation errors during the
tsvet run.

Ultimately we could do away with the tsc step entirely and output
compilation errors and our own custom errors in the tsvet step. This
would need tsvet support for --watch and friends to become a reality
practically speaking.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#680 (comment)

[myitcv]

@alexeagle - completely agree. That would be ideal. tsvet is something we can do today... and with relative ease, independent of the tsc compiler.

I see you've already commented on the issue that I believe is tracking this in TypeScript core.

Our work on tsvet is of course compatible with microsoft/TypeScript#3003 by virtue of our 'rules' being defined in terms of the compiler API.

[adidahiya]

Full-program linting is now possible thanks to @ScottSWu's work in #1363! Please try out the new APIs, let us know how they work out, and file follow up issues as necessary ❤️

edit: released in tslint@next v3.14.0-dev.0

[JoshuaKGoldberg]

Love it!