Skip to content
This repository was archived by the owner on Mar 25, 2021. It is now read-only.
This repository was archived by the owner on Mar 25, 2021. It is now read-only.

Lint Programs as a Whole #680

Closed
Closed

Description

@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.

Activity

  1. ashwinr commented on Sep 22, 2015

    @ashwinr
    Contributor

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

  2. jkillian commented on Sep 22, 2015

    @jkillian
    ContributorAuthor

    Possibly stuff like this: #577

  3. adidahiya commented on Sep 22, 2015

    @adidahiya
    Contributor

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

  4. dallonf commented on Sep 28, 2015

    @dallonf

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

  5. jkillian commented on Sep 28, 2015

    @jkillian
    ContributorAuthor

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

  6. dallonf commented on Sep 28, 2015

    @dallonf

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

  7. added this to the TSLint 3.0 milestone on Sep 30, 2015
  8. modified the milestones: TSLint 3.0, on Oct 14, 2015
  9. myitcv commented on Mar 4, 2016

    @myitcv
    Contributor

    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

  10. jkillian commented on Mar 21, 2016

    @jkillian
    ContributorAuthor

    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

  11. alexeagle commented on Mar 30, 2016

    @alexeagle
    Contributor

    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.

  12. myitcv commented on Mar 30, 2016

    @myitcv
    Contributor

    @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.

  13. alexeagle commented on Mar 30, 2016

    @alexeagle
    Contributor

    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)

  14. myitcv commented on Mar 30, 2016

    @myitcv
    Contributor

    @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.

  15. adidahiya commented on Jul 12, 2016

    @adidahiya
    Contributor

    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

  16. JoshuaKGoldberg commented on Jul 14, 2016

    @JoshuaKGoldberg
    Contributor

    Love it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions