Tslint: --fix is very slow if there are multiple issues

Created on 21 Mar 2018 · 9Comments · Source: palantir/tslint

Bug Report

__TSLint version__: 5.9.1
__TypeScript version__: 2.7.2
__Running TSLint via__: CLI

--fix is very slow if there are hundreds or thousands (957 in my case) of linting issues, which are fixable automatically. For example adding a bunch of new rules or changing your code style can introduce such cases.

This issue seems to be calling createProgram in a loop. Each call may take up to a second or two to finish (at least on Windows) and if it's called a thousand times, the program takes 15 minutes to finish.

This issue was probably introduced by https://github.com/palantir/tslint/pull/2864, which seems to be an important fix though.

The actual linting process is fast though.

I can share you a profiler dump privately, if needed.

TypeScript code being linted

Any project with a thousand linting issues, which are fixable automatically.

Actual behavior

Running the linter takes like 15 minutes to finish.

Expected behavior

The linter should finish very well within a minute.

Needs Proposal Enhancement 🌹 R.I.P. 🌹

Source

ljani

👍5

Most helpful comment

That's a known issue. If you have many style issues, you can run tslint without --project to fix those failures first. That should be way faster. Afterwards you can fix the remaining failures that require type information.

You can also use my alternative linter runtime to execute TSLint rules. It's optimized for speed. It can probably fix your whole project in a couple of seconds.
You can find all necessary instructions in the description: https://www.npmjs.com/package/@fimbul/valtyr

ajafff on 21 Mar 2018

👍3

All 9 comments

ajafff on 21 Mar 2018

👍3

@ajafff Thanks. I tried searching the issues for it, but didn't find anything. Is there an issue I could subscribe to and close this one?

ljani on 21 Mar 2018

It turns out there is no other issue tracking this performance problem. I only answered a similar question on Gitter. So this was only a known issue for me.

Unfortunately there's not much that can be done to fix this in the current implementation. There's no separation of concerns so the linter cannot know how to update the program (it already assumes too much implementation details to be 100% correct). Therefore it needs to read (and parse) everything from disk over and over again.
Incremental parsing mutates the original SourceFile object which could/will break API users.

ajafff on 21 Mar 2018

Thanks for the insight. I'll leave the issue open then.

The Fimbullinter project seems interesting, I'll give it a go.

ljani on 21 Mar 2018

That's a known issue. If you have many style issues, you can run tslint without --project to fix those failures first.

That's somewhat true. However, using this, e.g. w/ tslint -c and globs, there is a bug where tslint running on macOS will miss a ton of things (even after verifying that the files being missed are indeed part of the glob). These errors will then show up, for example, in a Linux CI environment.

Edit: I should clarify that this is only an issue when running through npm scripts / yarn.

bfricka on 10 Jul 2019

@bfricka if you're using globs, make sure to quote the glob strings. that way it uses node glob to expand them. otherwise, without quotes, the glob expansion is done by the shell, which can vary across different environments

adidahiya on 10 Jul 2019

👍1

Holy smokes. That worked. I had no idea it would use node-glob by forcing a string (instead of glob expansion). All the examples I've seen don't quote. Thanks!

bfricka on 10 Jul 2019