I prefer to have unused code detected during linting, but sadly, eslint has decided to kill off the APIs that support rules like `no-unused-modules`. Running a separate tool like this one or knip in place of a few lint rules just seems impractical.
dmix 32 minutes ago [-]
eslint is a good example of why coding in javascript is annoying. Your tools just constantly changing wildly over a version upgrade, so you look for a better one and find there's a new Rust linting tool but it's alpha and is missing half the features.
e1g 2 hours ago [-]
+1 for the idea. Enforcing hard boundaries between is surprisingly helpful for AIs to reason about how to structure their changes.
We recently rolled out our own static analysis using oxc-parser and oxc-resolver, and it runs surprisingly fast (<1s for ~100K LOC). For us, it was definitely worth adding this layer of defence against The Slop.
jayu_dev 2 hours ago [-]
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.
esafak 2 hours ago [-]
Looks good; I'm eager to try it. Do you have any questions?
Rendered at 21:10:50 GMT+0000 (Coordinated Universal Time) with Vercel.
We recently rolled out our own static analysis using oxc-parser and oxc-resolver, and it runs surprisingly fast (<1s for ~100K LOC). For us, it was definitely worth adding this layer of defence against The Slop.
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.