feat(lsp): multi deno.json resolver scopes

[nayeemrmn]

Closes denoland/vscode_deno#787.
Closes denoland/vscode_deno#938.

After this, remaining TODOs are:

• Separate TS type checking environments across deno.json scopes (different global declarations, tsconfigs etc).
• Inheritance of properties in workspace members. This must be fleshed out and implemented in the CLI first.

[dsherret]

Why remove the warn? It's sometimes useful to see.

[dsherret]

Ah, I see it was moved into the resolver. Nvm.

[dsherret]

LGTM!

[felipecrs]

Is it correct to say that with this PR I can remove my deno.enabledPaths from .vscode/settings.json provided each of these enabled paths already have a deno.jsonc?

[nayeemrmn]

@felipecrs The purpose of deno.enablePaths is to disable Deno for everything outside of those paths, perhaps you didn't need it in the first place.

[felipecrs]

Not really, that was exactly why I needed it. I had a project with both node.js and deno.

This means deno.jsonc will be discovered regardless of where it's set in the workspace, but once discovered, Deno will be enabled for the entire workspace.

Therefore, I still need deno.enablePaths for my node.js + deno projects.

Is this understanding correct?

[nayeemrmn]

@felipecrs Yes. However, if you like you can delete the deno.jsonc in your root directory and only have it in each Deno-enabled subdirectory. This will work now. You can then remove deno.enablePaths.

[felipecrs]

Perfect! I didn't have deno.jsonc in my workspace's root, only in my deno-enabled subdirectories.

I guess this means that, for my use case, I can remove deno.enablePaths after all. :)

[char]

This has broken my setup:

project1/
  mod.ts
  deno.json { imports: { myDep: "https://esm.sh/..." } }
project2/
  mod.ts
  deno.json { imports: { myDep: "./vendor/myDep.ts", project1: "../project1/mod.ts" } }
  vendor/
    myDep.ts

I want to use the vendored dependency at runtime - previously I could open the project2 subfolder in the editor and everything could work, but now anything imported from project1 inside project2 has broken IntelliSense when using types from myDep. This seems like a divergence from CLI behavior (when running Deno, everything is resolved using the initial deno.json config's import settings)

Where do I go from here? I can try a workspaces config to take advantage of #24246 but it would mean my parent deno.json config needs every subproject's dependencies in its import map, rather than only having relevant deps available to the import resolver

[nayeemrmn]

@char It's necessary to diverge from CLI behaviour when multiple scopes are involved because the editor doesn't have a concept of an entrypoint, for most usages it has to respect the nearest scope of each file. I'm not sure what to do in your case, there's no one for one substitute configuration, but it's an unusual case.