($495 Bounty) Type Aware Linting

[Boshen]

Background: https://typescript-eslint.io/getting-started/typed-linting/

Attempt 1:

• Linter experiment: TypeScript no-floating-promises via inter-process communication #2855
• feat(linter): typescript-eslint/no-floating-promises #2912

Attempt 2 (success!):

• linter: integrate tsgolint #12292
• feat(oxlint): experiment: add tsgolint integration #12343

[Bhavyajain21]

Can I be assigned?

[Boshen]

@Bhavyajain21 #2912 is getting there, do you wanna help that out or do you want to experiment with other setups?

btw the bounty was just a demonstration, it is now removed.

[Boshen]

https://typescript-eslint.io/getting-started/typed-linting/#how-is-performance

@valeneiko I have another idea. Is it viable to build and get all .d.ts + @types files and statically check against them? We would end up supporting some of the typing rules without sacrificing performance.

I think no-floating-promise can be done statically by marking a function as async just like how #[must_use] work in rustc 🤔

I'm not sure about the others rules, but the most important rules oxlint provide should be the ones checking for correctness. All the other ones can deprioritized.

[valeneiko]

I had a similar optimization in mind to make us call typechecker less. Basically if we have a list of functions marked async or returning a Promise we could use it to check some of the CallExpressions. And we would not need .d.ts, at least for the ones explicitly marked async or with explicit Promise return type annotation.

Generating .d.ts would take quite a long time for a limited benefit:

• TSC removes all async annotations, so we would have to look for functions returning Promise
• Return type on function that weren't annotated async in source will often be a union with a Promise instead of simple Promise
• It would not help with class X extends Promise, where function returns X. Which is a pretty common pattern.

I don't think this alone would be sufficient to cover no-floating-promise. It would be fairly easy to do for standalone functions, but once member method calls get involved, we would have to have a significat portion of TypeScript in order to resolve them.

[magic-akari]

The key issue is cross-file knowledge.
A lot of Type information relies on information from other files.

Do we need this cross-file support?
If so, then .d.ts is a shortcut to implementation.

[Boshen]

Do we need this cross-file support?

Multi-file analysis works under the --import-plugin flag.

[Boshen]

Current progress and conclusion from #2912:

The PR managed to build a ts server and communicate with it from the Rust side.

But we hit a blocker where we would end up rebuilding @typescript-eslint: we need to convert the typescript ast to our ast so we can have a matching span position to query on.

@valeneiko and I felt like it's not worth it to maintain all these code and see no performance improvements.

So instead, I propose the following:

Given that we are a static analysis tool, we should use static type information from typescript instead of getting them dynamically.

TypeScript is heading towards this direction by having explicit-module-boundary-types and isolated-declarations.

Since we now have the infrastructure for multi-file analysis, we can leverage this by reading and parsing .d.ts files, work out the semantics and query typing information statically.

There is going to be a lot edge cases, so what I'm going to do next is think of a minimal scenario, experiment and test on it.