Deno LSP does not recognize Deno.openKv when no-default-lib="true" is present in any file

[mgenereu]

Ignore this description. I had old .ts files in the Linux temp folder and the Deno LSP reads all .ts files in the workspace regardless if they're referenced by the opened file. Deno LSP versions before 1.32.2 only behaved like this when the offending file was open. Any declarations in the files are globally applied and override. Reference #9541 for continued discussion.

I'm not sure why #19801 was closed. Based on deno --version of those experiencing the issue, there's clearly two different behaviors between Windows and Linux/Mac. Is the deno.unstable flag being deprecated in favor of the declarative /// <reference lib="deno.unstable" />?

Reproduce:

1. Create file kv_test.ts:

Deno.openKv();

2. Toggle deno.unstable in VS Code.

Results:

• Windows: Error deno-ts(2551) appears and disappears immediately on toggle of deno.unstable.
• Linux: Error deno-ts(2551) always appears regardless of toggle of deno.unstable.

[mgenereu]

Ah ha! I'm not a Rust developer but I can bisect install versions of Deno. Deno version 1.32.1 works! I can toggle the VS Code setting and it toggles the error as expected. After installing 1.32.2, it presents the undesired behavior. I'll look through the diff between those releases and try to further shed light on the regression.

[mgenereu]

On each toggle from the Linux side, I can see the ts_server get an updated config including deno.unstable in the lib section.

{
    "type": "mark",
    "name": "request",
    "count": 15,
    "args": {
        "id": 16,
        "method": "configure",
        "compilerOptions": {
            "allowJs": true,
            "esModuleInterop": true,
            "experimentalDecorators": true,
            "isolatedModules": true,
            "jsx": "react",
            "lib": [
                "deno.ns",
                "deno.window",
                "deno.unstable"
            ],
            "module": "esnext",
            "moduleDetection": "force",
            "noEmit": true,
            "resolveJsonModule": true,
            "strict": true,
            "target": "esnext",
            "useDefineForClassFields": true,
            "useUnknownInCatchVariables": false
        }
    }
}

[nayeemrmn]

Can you share your config files? deno.json, vscode settings. Also do you have /// <reference no-default-lib="true" /> anywhere in your project?

[mgenereu]

Okay. This is kinda crazy. There is a file with /// <reference no-default-lib="true" /> and /// <reference lib="deno.ns" /> from when I tried Fresh awhile back sitting in the same folder as kv_test.ts. I'm not referencing the file from kv_test.ts but if it's opened in VS Code under Deno LSP 1.32.1, it takes effect and the error appears. When I close the file, the error goes away. On versions after 1.32.1, the effects of the file are always present regardless of being opened in VS Code.

[nayeemrmn]

I see, that's because of #9541. If a file makes global augmentations it becomes part of the environment while it's open. It's a design limitation for the moment.

[mgenereu]

Awesome. And 1.32.2 made it even more prevalent by loading "all the files" instead of "open files". Okay. I'm going to go clean up and get this documented in these issues for others. Thank you, @nayeemrmn !

[nayeemrmn]

FWIW in typical cases the problem is the reverse, i.e. if you (on purpose) have a file with this directive in your project, you want it to apply even when it's closed.

Let's continue in #9541