type aware linting blog post #424
Conversation
✅ Deploy Preview for oxc-project ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Boshen
force-pushed
the
tsgolint
branch
2 times, most recently
from
b30e6c1 to
757bd6e
Compare
| - no-floating-promises | ||
| - no-misused-promises |
There was a problem hiding this comment.
| - no-floating-promises | |
| - no-misused-promises | |
| - `no-floating-promises` | |
| - `no-misused-promises` |
nit
| - no-floating-promises | ||
| - no-misused-promises | ||
|
|
||
| The next version will enable all type-aware rules. |
There was a problem hiding this comment.
As in: The next major or the next minor version?
|
|
||
| ## Performance | ||
|
|
||
| Our testing shows that large repositories, which previously took several minutes to run with `typescript-eslint`, |
There was a problem hiding this comment.
Do we have more precise metrics?
|
|
||
| ## Type-Aware linting | ||
|
|
||
| Please refer to |
There was a problem hiding this comment.
It might still be worth to add a bit of an overview to what other type-aware linters are doing (e.g. biome)?
|
|
||
| All type-aware rules are written directly against these shimmed APIs. | ||
|
|
||
| While this isn't the recommended approach, it works! |
There was a problem hiding this comment.
Will this possibly change in the future?
|
|
||
| - [Biome 2.0](https://biomejs.dev/blog/biome-v2/) with its own type inference implementation. | ||
|
|
||
| We determined that writing our own type inferencer or type checker was not feasible due to budget and time constraints, |
There was a problem hiding this comment.
If not elaborate earlier (see comment before), might be worth to mention accuracy too?
There was a problem hiding this comment.
I suggest removing the reference to "budget". The idea that commercial imperatives and open source ethos inevitably clash and lead to worse outcomes has currency in some quarters. Mentioning financial considerations here might tend to fuel that argument. And I don't think it's fair here - we were struggling with the infeasibility of building a reliable type inference system long before Oxc became part of Void 0.
More generally: Isn't the point here that we decided the surest route to building complete and accurate support for type-aware linting, and keeping up-to-date with TS, is to lean directly on the TS compiler? (following TS-ESLint's example)
|
|
||
| Shimming TypeScript's internal APIs carries some risk. However, the TypeScript AST and its visitor are actually quite stable. | ||
|
|
||
| We accept this risk and will fix breaking changes when upgrading `typescript-go`. |
There was a problem hiding this comment.
Worth highlighting the reduced risk for users through this?
| The core of this new functionality is [oxc-project/tsgolint](https://github.com/oxc-project/tsgolint). | ||
|
|
||
| The tsgolint project was initially prototyped as [typescript-eslint/tsgolint](https://github.com/typescript-eslint/tsgolint). | ||
| However, the `typescript-eslint` team decided not to allocate development resources to this prototype, as they plan to continue their work on `typescript-eslint` for typed linting with ESLint. |
There was a problem hiding this comment.
Worth pointing out (in a different chapter) what is the USP of using tsgolint with oxlint (instead of, e.g., waiting for typescript-eslint to be "go-powered")?
|
More questions:
|
No description provided.