You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 25, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 25, 2021. It is now read-only.
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.
Reacted by Chris Yungmann and Bahaà Addin Balashoni
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
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
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.
@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.
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:
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)
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 ❤️
Activity
ashwinr commentedon Sep 22, 2015
what additional features does this enable? we're not linting types yet anyway.
jkillian commentedon Sep 22, 2015
Possibly stuff like this: #577
adidahiya commentedon Sep 22, 2015
basically any rule that needs to inspect types will need all the type information from the compilation path in order to work reliably
dallonf commentedon Sep 28, 2015
It'd at least be nice to pass a glob to
tslintand lint multiple files.jkillian commentedon Sep 28, 2015
@dallonf When using it programmatically I assume? (Since obviously a glob will work when using it via the CLI)
dallonf commentedon Sep 28, 2015
@jkillian I didn't know that was supposed to work ;) Created a ticket for my seperate issue: #688
myitcv commentedon Mar 4, 2016
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
tslintjkillian commentedon Mar 21, 2016
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 commentedon Mar 30, 2016
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),--skipDefaultLibCheckand so on. Otherwise the typecheck will fail whentslintruns, 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 commentedon Mar 30, 2016
@alexeagle - the approach we are following with
tsvetis to reference the sametsconfig.jsonthat is referenced bytsc.As it stands, we only run
tsvetonce a compilation viatschas succeeded. This obviates the need to ignore/dedup the compilation errors during thetsvetrun.Ultimately we could do away with the
tscstep entirely and output compilation errors and our own custom errors in thetsvetstep. This would needtsvetsupport for--watchand friends to become a reality practically speaking.alexeagle commentedon Mar 30, 2016
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:
myitcv commentedon Mar 30, 2016
@alexeagle - completely agree. That would be ideal.
tsvetis something we can do today... and with relative ease, independent of thetsccompiler.I see you've already commented on the issue that I believe is tracking this in TypeScript core.
Our work on
tsvetis of course compatible with microsoft/TypeScript#3003 by virtue of our 'rules' being defined in terms of the compiler API.adidahiya commentedon Jul 12, 2016
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@nextv3.14.0-dev.0JoshuaKGoldberg commentedon Jul 14, 2016
Love it!