Deno.enablePaths conflicts with vscode TSServer when used in a monorepo

[evelant]

Describe the bug

In a pnpm monorepo I have a subdirectory which contains a Deno project. This is a common configuration with Supabase. I have the deno plugin configured to only run in the deno project subdirectory, like so:

    "deno.enable": true,
    "deno.unstable": false,
    "deno.enablePaths": [
        "./supabase/functions/",
    ],
    "deno.config": "./supabase/functions/deno.jsonc",

It seems as though this bug has resurfaced: #668

With this configuration the Deno language server appears to ignore enablePaths and auto-loads the package.json from the parent directory ( Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json")

When I attempt to edit Deno code it appears as though the TS LSP and the Deno LSP are "fighting" each other -- errors are highlighted, disappear, invalid errors are highlighted, disappear, errors are highlighted again, and so on. Sometimes it settles down after a time but as soon as one character is changed in the file it happens again.

Deno LSP output:

Starting Deno language server...
  version: 1.33.2 (release, aarch64-apple-darwin)
  executable: /Users/imagio/.cargo/bin/deno
Connected to "Visual Studio Code" 1.80.0
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Enabling import suggestions for: https://deno.land
Server ready.
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
Warning: "options" configuration is deprecated. Please use "flat" options instead.
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Enabling import suggestions for: https://deno.land
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
client asked to cancel request 136, but no such pending request exists, ignoring
client asked to cancel request 135, but no such pending request exists, ignoring
client asked to cancel request 138, but no such pending request exists, ignoring
successfully cancelled request with ID: 141
successfully cancelled request with ID: 142
successfully cancelled request with ID: 143
successfully cancelled request with ID: 144
successfully cancelled request with ID: 145
successfully cancelled request with ID: 139
client asked to cancel request 140, but no such pending request exists, ignoring

I'm guessing the client asked to cancel request 136, but no such pending request exists, ignoring might be indicative of the problem.

To Reproduce

1. Enable deno in a subpath of a monorepo
2. Observe error highlighting doesn't work correctly, package.json is picked up outside of enabled path

Expected behavior

1. Deno LSP should not pick up anything outside of enablePath. (Don't resolve package.json in a parent dir outside of enablePath)
2. Deno LSP should correctly highlight errors

Screenshots

Versions

vscode: 1.80.0 deno: 1.33.2 extension: 3.19.1

[bartlomieju]

I believe this is the exact same problem as #581, let's continue there.

[evelant]

@bartlomieju Maybe related but I don't think it's exactly the same problem. I'm not using a multi-root workspace like people in the other issue. I'm only using enablePaths.

[evelant]

Just to verify I created a new vscode profile that was empty except for the Deno plugin. Opening my project in this deno-only profile resulted in the same bug. It seems vscode_deno will resolve package.json in a parent directory no matter what the configuration is.

[bartlomieju]

Does that match the behavior reported in #838?

[evelant]

Deno is still mostly unusable in a monorepo due to this issue ☹️

I'm forced to use Deno since it's a runtime on which supabase edge functions is based and this issue makes it super painful.

[evelant]

Here's a recording, this happens constantly on every edit and when opening any file when you use the Deno vscode plugin in a monorepo that also uses plain TS

Screen.Recording.2023-09-25.at.20.22.23.mov

[ben-laird]

+1 to the above. I'm currently using Deno in a small monorepo utilizing a non-edge version of Prisma (therefore need a node_modules directory because of Prisma's codegen quirks). While the cli works without a hitch, the language server cannot resolve @prisma/client although it suggests importing from @prisma/client.

My guess is it's caused by the lsp not looking at the current directory's package.json, but if that's not the case let me know and I'll file a different issue with reproduce repo.

[nayeemrmn]

@evelant Are you still experiencing this? I'm not sure detecting package.json outside of the enabled scope is the issue, the runtime will detect it on execution anyway and there shouldn't be diagnostics resulting from that. Can you show what kind of diagnostics are appearing if it's still happening?

[evelant]

Sorry, but I've removed all Deno code from my project, it was causing too many problems.

[nayeemrmn]

That's a shame to hear. Unfortunately we don't have a reproduction or much info to go off, so I'll close this for the time being.