📝 If I Wrote a Linter, Part 1: Architecture
I'm writing a series of blog posts on zany ideas for where we could take a web linter next. This is part 1 of ~4, on the core architecture. Let me know what you think! 😊
https://www.joshuakgoldberg.com/blog/if-i-wrote-a-linter-part-1-architecture/?utm_source=bsky
I'm writing a series of blog posts on zany ideas for where we could take a web linter next. This is part 1 of ~4, on the core architecture. Let me know what you think! 😊
https://www.joshuakgoldberg.com/blog/if-i-wrote-a-linter-part-1-architecture/?utm_source=bsky
Comments
TypeScript For Type Awareness: Probably a good bet until something dethrones or seriously competes with TS (after that, who knows)
Built-In TypeScript Support: 👍 Any help to rule authoring experience is good to take. Especially if the target is plainly TS.
* JS-like (.js, .json, .ts)
* MD-like (.html, .md)
* Styles (.css, .scss)
Why have a dedicated linter for each? What is unique about the MD-like & Styles langs that would make ESLint / this hypothetical linter suboptimal?
But flipping once more, I am convinced that ESLint would not be a serious contender to elm-review if it were to lint Elm code, mostly because of multi-file analysis. So there's some boundary where it's not good enough.
Is there anything in a CST that we couldn't get from a combo of the TS AST + scope manager + type info?
For instance, can you point to the exact position of "=>" in "a => 1"?
According to astexplorer, the info is missing with typescript-eslint/parser, but it's in the TS AST 👍
Yeah this gets ideated sometimes in tseslint as maybe a "shortcut" API? Like, if you just need to know whether a thing is a Promise, and its declarations are fully known in the scope manager, just use that?