I wonder if it would make sense to move rules that depend on types to a typescript plugin (example: https://github.com/Microsoft/typescript-styled-plugin). Though that wouldn't be an eslint plugin anymore, and we might come full circle with tslint (https://github.com/Microsoft/typescript-tslint-plugin).

Related: #134

I also noticed in a one of my projects that running createProgram is super slow, basically because it parses/typechecks all the files. I think it should be possible via the language service to do that in a lazy / incremental way.
However I haven’t figured out how to do that myself, partly because I don’t even know where all the typescript API docs are, since all the docs I have found are quite lacking.

Full scan of my project takes more than 5 minutes with parserOptions.project specified. This is so long

cc @typescript-eslint/core-team

Is it possible for us to run the parser in "isolatedModules" mode?
Or would we lose too much information from that?

There's been some discussion elsewhere about how plugins could gather some information in advance, before any linting begins, which would allow them to get some information that could then be shared among plugin rules. For example, eslint-plugin-import has a use case where they went to parse all files being linted to find imported files and construct a dependency graph. From what I've seen here, constructing a Program from all files being linted could be a similar use case.

Along those lines, I would recommend creating an RFC in the ESLint RFC repository. It would be a great way to get some opinions from the ESLint core team, as well as allow other stakeholders such as eslint-plugin-import a chance to contribute their ideas and hopefully land on a sensible design that works for all.

I'll keep an eye out on the ESLint side for when that RFC is created. 😄

That makes sense, and the import plugin case sounds quite similar! I'll try to take a look at opening the RFC sometime over the next week or two.

What I've also noticed is that after the first TS file is scanned the following ones (even if they are JS) slow down when linting. My solution was to lint them separately

"lint": "eslint . --ext .js,.jsx && eslint . --ext .ts,.tsx",

I believe eslint-plugin-import cheats and caches information between rules and files in module scope, in the import-map file. We could do the same and cache a compiled program.

https://github.com/benmosher/eslint-plugin-import/blob/master/src/ExportMap.js#L18

Ran some tests against master.

// withProject.eslintrc.js
module.exports = {
  extends: [path.resolve(root, '.eslintrc.json')],
  parserOptions: {
    project: path.resolve(root, 'packages/typescript-estree/tsconfig.json'),
    tsconfigRootDir: path.resolve(root, 'packages/typescript-estree'),
  },
  rules: {
    [`${prefix}/promise-function-async`]: 'error',
  },
}

$ node --inspect-brk node_modules/.bin/eslint -c=./tests/perf/withProject.eslintrc.js --ext .js,.ts ./packages/typescript-estree

> Profiled time = 3670 ms

// withoutProject.eslintrc.js
module.exports = {
  extends: [path.resolve(root, '.eslintrc.json')],
  parserOptions: {},
  rules: {},
}

$ node --inspect-brk node_modules/.bin/eslint -c=./tests/perf/withoutProject.eslintrc.js --ext .js,.ts ./packages/typescript-estree

> Profiled time = 1836 ms

There is a definite slowdown present (1834 ms), however I went digging using the node profiler (--inspect-brk) to double check where the extra time was being spent.

The raw chrome profile data from the runs (you should be able to load the files into the chrome developer tools): typescript-eslint-profiles.zip

We use the typescript compiler API createWatchProgram. This uses the provided tsconfig to build and parse every file in the workspace ahead of time.
typescript-estree also caches the resulting program and reuses it. This means that we only pay the cost of parsing and generating types once per configured tsconfig.json.

Unfortunately, the time cost associated with constructing the program (even once) is going to be proportional to the size of your workspace.
For the typescript-estree codebase, that's 6000 lines of code across 12 files, the cost of constructing the program once is around 1800 ms.

At this point in time, I don't know what we can do about this cost. I don't think there's a way for us to circumvent this one off cost. We more or less need every single file in the project parsed by typescript so that we can guarantee for the rules that all imported variables are properly typed.
It makes sense to do this check all at once to make sure we don't duplicate the work, though an argument could be made for only parsing the files (and their dependency tree) as they're presented by eslint, however I don't think the typescript compiler API provides a mechanism for doing this in such an incremental way.

If anyone has any suggestions for this, I'd love to hear it.

For users that use the CLI, there's nothing at all we can do about the cost - once the lint finishes, node exits, and with it the cache is gone. This means you have to pay it once per cli run.

For watch mode (/ IDE plugins) - I haven't profiled it, but I'd assume that these modes are run more like a persistent server, meaning they should be able to take full advantage of the caching mechanism.

For users that use the CLI, there's nothing at all we can do about the cost - once the lint finishes, node exits, and with it the cache is gone. This means you have to pay it once per cli run.

I think TypeScript 3.4 .tsbuildinfo might be helpful here. It's something that TypeScript ESLint should assure it not left unused.

The 3.4 RC is out.

For anybody following along for the perf piece, please try the latest release - 1.5.0 :)

Still very slow

Hey @Djaler

What's your codebase look like?
How many files are there?
Are you linting a multi tsconfig repo?
What is the speed difference between linting with and without type information rules?
What rules are you using?
Have you got a link to the repo? Or a gist repro case?
What versions of the plugin/parser/TypeScript/node are you using?
Are you running eslint in watch mode? Via your ide? Via CLI on your entire repo?

Your comment "still very slow" contains absolutely nothing useful for us to action or investigate, and only serves as notification spam for all the participants and watchers of this issue.

In future, please give us some information, or at least something more constructive than 3 words.

I am also seeing slowness in our repo compared to tslint, even without specifying a project.

tslint with project - 20s
eslint with project - 96s
eslint without project - 57s

How many files are there?
1000ish

Are you linting a multi tsconfig repo?
No

What rules are you using?
recommended + airbnb + prettier

What versions of the plugin/parser/TypeScript/node are you using?
plugin/parser - 1.5.0
typescript - 3.3.4000
node - 10.15.0

Are you running eslint in watch mode? Via your ide? Via CLI on your entire repo?
CLI, non-watch