Open Boshen opened 2 months ago
Can I be assigned?
@Bhavyajain21 https://github.com/oxc-project/oxc/pull/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.
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.
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:
async
annotations, so we would have to look for functions returning Promiseclass 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.
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.
Do we need this cross-file support?
Multi-file analysis works under the --import-plugin
flag.
Current progress and conclusion from https://github.com/oxc-project/oxc/pull/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.
How would file-local type linting work though? Since the TS proposal only types exports
/attempt #3105
with your implementation plan/claim #3105
in the PR body to claim the bountyThank you for contributing to oxc-project/oxc!
Background: https://typescript-eslint.io/getting-started/typed-linting/
Attempt 1: