Incremental checks

[gajus]

As you already know, I wrote an ESLint rule that uses ts-unused-exports. However, the problem is that currently anytime that any file is changed this rule will trigger ts-unused-exports check of the entire project – that's slow and blocks the ability to use this rule in ESLint/IDE context.

Is there a way to build some sort of a cache or another optimization that would make ts-unused-exports faster on re-runs?

Another user suggested that it might be possible to optimize ts-unused-exports integration with ESlint if it utilized parsed source produced by eslint-plugin-import. That could be another option.

Surfacing to start a conversaiton.

[mrseanryan]

hi @gajus

when running ts-unused-exports you could try passing a list of files to process:

const result = analyzeTsConfig("../simple/tsconfig.json", ["src/a.changed.ts", "src/b.changed.ts"]);

But then that might make some false positives 🤔

If there was a way to pass:

• changed files
• all files that import those, up to the 'root'

const result = analyzeTsConfig("../simple/tsconfig.json", ["src/a.changed.ts", "src/b.changed.ts", "src/c.imports-a.ts", "src/d.imports-c.ts", "src/e.imports-b.ts"]);

Then that should work ...

[gajus]

If there was a way to pass:

I think I can do that. Let me give that a try.

[mrseanryan]

The idea to parse the output of eslint seems like a major restructuring- probably need to add an abstraction over the TypeScript model…
——
idea: could add an option like ‘—incrementalScan=[path to saving directory]’:

• look for persisted state (the export map) in a file ‘.ts-unused-exports.cache.json’ in the given directory
• by default the directory is the same as that of the tsconfig file
• if cache exists: only scan files with modified timestamp newer than the timestamp of the cache. also need to scan any new files.
• else perform full scan
• at end of scan, persist the export map to the file

Optimisation: if a list of files is also provided, then no need to check for timestamps, just scan those files only.

The cache file needs an internal serialisationVersion so can be changed in future…

The serialization needs to be isolated so that future changes to the export map don’t break the deserialisation …

This would need a spike to make sure it really works…

—-
problem: how to handle stale usage counts ?
could record which file each usage came from. so usageCount is replaced with usageFiles = an array of full file paths.
so at start, files that have changed should be removed from all usagefiles. and of course their entries in exportMap need to have their exports reset (but not their usageFiles).

[mrseanryan]

@gajus I could do a spike on this,
hopefully later this month.
will ping you when i have something…

[mrseanryan]

hm I've not got around to this ...

Will mark as 'help wanted' in case someone else is available ...