Is deno lsp intended ONLY for use with Deno?

[tsujp]

Excited about Deno 2, I (used-to) use Deno 1 quite a lot until npm compatibility issues drove me back to Node, and now I currently use Bun.

One of the things I very much like(d) about Deno is the integrated LSP. However, the docs for Deno 2 now state: [...] specifically tailored to provide a Deno view of code. I don't plan on using Deno as a runtime soon, I'm in the middle of a lot of projects and so forth. I would like to use Deno for it's LSP and linter though, replacing a Node.js installation with typescript-language-server and other tools.

However it looks like using Deno as an LSP for a non-Deno project is... painful. Deno appears to require a deno.json for it to detect where a project is, and it doesn't (by my fumbling) seem to load or respect tsconfig.json and instead requires you to specify such options within deno.json.

There are also custom LSP notifications e.g. deno/didUpgradeCheck which break lsp-mode in Emacs for example.

Am I right in understanding that deno lsp is ONLY intended for use with Deno projects? If that's true this feels like a rehash of Deno 1. Now I need to either go all-in on Deno (something which, amongst other things necessitated moving to Deno 2) or add yet another configuration file at the top of my repo: deno.json and then maintain a bunch of hacked together import maps specifically for Deno so it can understand and function as an LSP in a non-Deno project. Let's be realistic, outside of messing around this isn't going to happen and that means Deno adoption goes down, something which resulted in Deno 1's death.

If my understanding is correct I think this is the wrong approach; a useful tool deno lsp won't be used (and thus Deno won't be used) by as many as it could be because of what feels like artificial limitations.

I was one of the people who frantically tried to use web-only APIs in the Deno 1 days, often spending (and in hind-sight: wasting) dozens of hours due to the inability (then) of Deno 1 to accurately use and be compatible with the necessary evil that is npm. This is one of the reasons why Bun shines; it had npm compatibility from day 1 and continues to put a lot of effort into supporting Node.js APIs, even though I think we all agree a lot of said APIs should be dead.

I fear this is happening again, albeit to a lesser degree, precisely because the LSP client doesn't seem generic (when it could be).

[jakubdonovan]

I also use denols in Deno and non-Deno projects, and as you mentioned, it doesn’t function properly without a deno.json in the root of the project. #26223