@deno-types breaks at 1.43.4

[vicary]

Version: Deno 1.43.4, Deno 1.43.5

---

Given the following import

// @deno-types="npm:@types/pg@^8.11.5"
import pg from "npm:pg@^8.11.5";

The following function call is correctly typed until Deno 1.43.3:

pg.types.setTypeParser(
  pg.types.builtins.DATE,
  (val) => Temporal.PlainDate.from(val),
);

After upgrading to Deno 1.43.4+ pg.types fails to resolve its types, subsequently leading to a lint failure on (val) => being implicit any.

---

In VS Code, navigating to the type definition shows [errored].

But the language server output doesn't seem to report anything.

[dsherret]

1. This happens to me in Deno less than 1.43.4
2. Change it from @deno-type to @deno-types
3. Run deno check --all main.ts. You'll see something like this indicating missing @types/node package:

   > deno check --all main.ts
   Check file:///V:/scratch/main.ts
   error: TS2580 [ERROR]: Cannot find name 'Buffer'.
   export type TypeParser<I extends (string | Buffer), T> = (value: I) => T;
                                              ~~~~~~
       at file:///V:/.cache/deno/npm/registry.npmjs.org/pg-types/4.0.2/index.d.ts:67:44
   ...etc...
   

4. I bet in your code you originally had /// <reference types="npm:@types/node" />? It seems to not be working in the lsp right now (I opened /// <reference types="..." /> stopped working in TypeScript files in the LSP in 1.43.0 #23879). Instead do this and it will make things work:

   import type {} from "npm:@types/node";

[vicary]

Thanks for replying @dsherret!

1. I can replicate that, but only occasionally. It seems that reinstalling Deno is reloading the cache and it has a chance of failing for each reload.
2. It is @deno-types in my code, sorry for typo in the issue.
3. I can replicate that, the errors even goes into Deno itself.
   
4. No I didn't have that, but I added /// <reference lib="deno.unstable" /> myself.
   Using import type {} from "npm:@types/pg"; does remove the type errors for a while. But it starts failing again shortly after I save the file, it never recovers from the type errors even with the new import.

Attaching my `main.ts` here for more context, it is a Deno Fresh project.

/// <reference no-default-lib="true" />
/// <reference lib="dom" />
/// <reference lib="dom.iterable" />
/// <reference lib="dom.asynciterable" />
/// <reference lib="deno.ns" />
/// <reference lib="deno.unstable" />

import "$std/dotenv/load.ts";

import { start } from "$fresh/server.ts";
import config from "./fresh.config.ts";
import manifest from "./fresh.gen.ts";

await start(manifest, config);

[dgreensp]

I think I'm running into the same problem.

Previously, this worked to apply particular types to a JS file:

// @deno-types="./foo.d.ts"
export * from "./foo.js";

Recently, it started to work flakily, and as of 1.43.5 it might be not working at all now.

[dgreensp]

Correction, it is working flakily.

For example, after editing deno.jsonc to add an unrelated lint rule: Errors start showing up across the project.

After modifying the file containing the code I quoted in the previous comment and re-saving it: Errors go away.

[bombillazo]

Hey @nayeemrmn , does #23902 also fix this issue? We had to go back to 1.43.3 to avoid this issue.

[rossholdway]

Have to say this is a super frustrating bug.

I had Redis imported import { createClient } from 'redis'; via import map { "redis": "npm:@redis/client@1.5.16" } which was working fine, until it started reporting all types as any.

Only now realised this is the cause (upgrading to v1.43.4 or v1.43.5). Downgrading to v1.43.3 fixes the issue as @bombillazo mentioned above.

[nayeemrmn]

Hey @nayeemrmn , does #23902 also fix this issue? We had to go back to 1.43.3 to avoid this issue.

Yes! Looks like #23902 restores the behaviour from 1.43.3.

For example, after editing deno.jsonc to add an unrelated lint rule: Errors start showing up across the project.

After modifying the file containing the code I quoted in the previous comment and re-saving it: Errors go away.

I think I know why that's happening, will look into it.

[osddeitf]

@nayeemrmn this may be related, I upgraded to v1.43.5 from v1.43.1, and now, detected types from:
import { Tokenizer } from "npm:parse5@7.1.2"
changed from parse5/7.1.2/dist/tokenizer/index.d.ts to parse5/7.1.2/dist/tokenizer/index.js

Will your PR fix that as well?

[nayeemrmn]

@osddeitf Yes, I believe it should

[dgreensp]

I just want to say I am also seeing errors about symbols not being found, or being used as a type when only found as a value, or vice versa (sorry I didn’t note down the exact error), in the form of red squiggly lines appearing in VS Code, that do not seem to be related to either NPM or deno-types, but that go away while I’m clicking on files in the sidebar. Transient errors. Noticeable upon changing deno.json or a setting that restarts the language server. This feels like the biggest regression in Deno quality of experience upon upgrading in a while. I guess it makes some sense there would be glitches if there were large changes to how the language server works. And from other comments it sounds like downgrading Deno is a possibility if I need to; I’ve never tried that.

…

On Tue, May 21, 2024 at 8:10 AM osddeitf ***@***.***> wrote: @nayeemrmn <https://github.com/nayeemrmn> this may be related, I upgraded to v1.43.5 from v1.43.1, and now, detected types from: import { Tokenizer } from ***@***.***" changed from parse5/7.1.2/dist/tokenizer/index.d.ts to parse5/7.1.2/dist/tokenizer/index.js Will your PR fix that as well? — Reply to this email directly, view it on GitHub <#23878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGBJSVAV2FO2ZVZFYK2ETZDNPWFAVCNFSM6AAAAABH5LNG4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRSHA2TMNRZHE> . You are receiving this because you commented.Message ID: ***@***.***>

[vicary]

@nayeemrmn After upgrading to 1.43.6, the only reliable way is the workaround of importing the type separately.

import type {} from "npm:@types/pg";

With @deno-types alone it is still failing in the exact same way, is there any internal cache of Deno that I should clear before retrying?

[nayeemrmn]

@vicary For me it works after editing the file one time, as mentioned in #23878 (comment). Can you check this?

[vicary]

I can reliably reproduce the error by relaunching VS Code or restarting Deno Language Server via command palette.

Screen.Recording.2024-05-23.at.05.03.52.mov

[nayeemrmn]

@vicary Try just adding a space at the end of the file while the red squiggly is there. Do they go away?

[vicary]

@nayeemrmn Yes, saving the file does make it go away. Is it meant to behave like this on each start?

[bombillazo]

Restarting the extensions or Deno server may also help. Its worked for me when cached deps get wacky or undetected sometimes.

[vicary]

@bombillazo Restarting via either means is the exact method to reproduce the issue right now. I am sorry, but that is the opposite of helping in this context.

[nayeemrmn]

@dgreensp @vicary The secondary issue appears to be fixed by denoland/deno_graph#487, please try it out with deno upgrade --canary!

[vicary]

@nayeemrmn Confirming that canary 14a74600de6f1c206ffe4750f6cb6da59657db8e fixes the issue, thanks a lot!