Not yet, currently it supports typescript path aliases and ESM imports/exports map. So industry standard I would say.

I don't think making plugins system is feasible because project focuses on performance. It's build in Go, so compiled language, so it's not easy to extend it like you can with JavaScript based tools.

But definitely I would like to support some reasonable amount of leading frameworks/build tools if they define some syntax / resolving mechanism that is beyond ESM specification.

I didn't test deno, but I guess it should work. Deno is just a runtime, imports/export are the same, compliant with JS specs.

But if it won't work feel free to open issue on GH :)

Imports are not the same; they usually need to be resolved using deno.json.

Oh didn't know that! I will take a look over the weekend

eslint is also a good example why Javascript runtime is bad choice for static analysis tools. The biggest problem is that it's single threaded.

Recent release of concurrency mode in eslint promised approximately 30% linting speed increase.

So now it uses multiple threads instead of one, and you got only 1.3x improvement. In any compiled language like Rust or Go you should expect time improvement that correlates with number of CPU cores engaged.

You can use worker threads in JS, but unfortunately sharing data between threads in context of static analysis, where there is a lot of deeply nested objects (AST) or basically a lot of data in general, is slow because it needs to be serialised and deserialised when it's passed between threads.

Javascript based tools for codebases with 1m+ lines of code becomes unusable :/

Nice! I’ve come to similar conclusions recently, with the recent increase in code changes velocity, solid static analysis is more important than ever.

When it comes to the performance, I've learned that reading code from file system and parsing it takes most of the time. Then resolving modules takes a little also.

Once that is done, running different checks is almost instant - like miliseconds.