LSP & deno check differ

[NfNitLoop]

The LSP (or, well, the Deno VSCode plugin) and deno check differ about whether these types are correct:

// OK in LSP & `deno check`:
function myFetch(input: FetchParams[0], init?: RequestInit) {
    const signal = init?.signal
}

// OK in `deno check`, but not LSP.
function myFetch2(input: FetchParams[0], init?: FetchParams[1]) {
    // LSP says: Property 'signal' does not exist on type 'RequestInit'
    const signal = init?.signal
}

type FetchParams = Parameters<typeof fetch>

Versions:

> deno --version
deno 2.1.9 (stable, release, aarch64-apple-darwin)
v8 13.0.245.12-rusty
typescript 5.6.2

Identifier
denoland.vscode-deno
Version
3.43.3
Last Updated
2025-01-30, 15:23:31

[marvinhagemeister]

Not able to reproduce this. When you hover over the error shown in vscode, does the error code at the end have the format deno-ts(<number>) or ts-(<number>)? If it's the latter than the Deno LSP is not active in the project. The extension activates itself for a project when a deno.json is present or the Deno: Enable command is run from the vscode command palette.

[NfNitLoop]

Yep, the error is from deno-ts(2339).

[NfNitLoop]

Hmm, if I take my minimal reproduction (min.ts) and put it in a fresh Deno project, I can't reproduce it either.

The non-minimal reproduction can be found here:

https://github.com/diskuto/rss-sync/blob/v2.0.2/src/aborter.ts#L25

(update): One tip for reproduction -- the LSP may initially show that all types pass. Go to the above line, delete the last character and re-add it to consistently trigger the behavior.

[nayeemrmn]

Hmm I can reproduce in 2.1.9 but looks like it's already been fixed in main. @NfNitLoop Can you try deno upgrade --canary to check?

[NfNitLoop]

> deno upgrade --canary
Current Deno version: v2.1.9
Looking up canary version

Found latest canary version 795ecfdca60d22183babdf887f7f66500c3983b3

👍 Confirmed, that fixes it for me too. Glad it was fixed so quickly. Sorry about the duplicate report!