[Linter] Make `deno lint` work in VScode without deno server

[yhnavein]

Is your feature request related to a problem? Please describe.

I wanted to use deno linter instead of eslint in VSCode for the project that is not deno-specific. I run deno lint on my project's code and the issues it finds are very useful for me, but I hate fixing them from the console, and I would greatly appreciate to see them as... well... lint output in the VSCode. But it seems it does not work :( Is it possible to have this functionality in this extension?

My workspace config I tried to use:

{
    "deno.enable": false, // As I don't want to use deno. Deno will not handle imports (standard imports; dependencies defined in package.json)
    "deno.lint": true,
    "eslint.enable": false
}

After restarting VSCode I don't see any linting messages in VSCode. It looks like deno.enable: false turns extension off.

And screenshot showing that indeed it's not working:

Describe the solution you'd like

I would love to use deno lint in the VSCode without enabling deno support. It should be possible, because deno lint works fine from the terminal. And I would love to see these warning/errors marks directly in the code

[bartlomieju]

I recently was messaged by other people interested in using deno_lint on Node based projects, and they want to run it in devcontainers as well. I think this is reasonable request, @dsherret @kitsonk what would you suggest as the best way forward?

[dsherret]

I think it would be a decent amount of work to implement and maintain.

1. We'd need a way to disable ts/dep diagnostics, code actions, etc. in deno lsp
2. Then a way to get it to not disable ts diagnostics in typescript-deno-plugin

I wonder if this might be better suited for dlint to provide then have a separate vscode extension.

[kitsonk]

I wonder if this might be better suited for dlint to provide then have a separate vscode extension.

Yes, I think that is a better solution. It doesn't require an 80mb executable. vscode_deno and the Deno CLI are really designed together. A standalone dlint LSP and vscode extension would make a lot more sense, and not be overly complicated to do. We could consider refactoring the integration code in the existing LSP to an "lsp" feature in deno_lint, so there would be minimal duplication of code too.

[bartlomieju]

Thanks for opinions! That definitely sounds like a good idea.

[mjgerace]

Any way I can help move this along?

[canadaduane]

With progress in deno's linter and the deno vscode extension, has it become easier to implement a standalone dlint LSP and VSCode extension?