NfNitLoop
commented
5 months ago I noticed the difference between deno lint and VSCode yesterday and was asked to make a bug about it. I think this is the same issue. LSP = Language Server Protocol, which is what VSCode uses to fetch problems/hints, ya?
Context from Discord:
It looks like when I have "name", "version", and "exports" defined in deno.jsonc, then deno lint knows to check for no-slow-types:
error[no-slow-types]: missing explicit type in the public API
But the VSCode editor doesn't. even if I try to enable the rule "no-slow-types". I was hoping I could easily find them all and add some annotations to disable no-slow-types on all my Zod types. 😑 (There were other valid errors, where I'd forgotten to annotate return types of functions, for example.) Hah, weird, while I can't lint.rules.include no-slow-types to make it get checked in VSCode, I can .exclude it to make it not happen in the CLI.
This is another case where no-slow-types behavior is diverging from the behavior of other lints. Similar to what I mentioned in this ticket, IMO the best solution is to make it act more like existing lints where possible. Does making no-slow-types a "normal lint" in the other case make it easier to add to the LSP? 🤞
A little complicated because it requires having a ModuleGraph, but we should look into a way to show no-slow-types diagnostics in the LSP w/ quick fixes for JSR.