@deno-types breaks at 1.43.4 about deno HOT 17 CLOSED

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.

from deno.

Have to say this is a super frustrating bug.

I had Redis imported import { createClient } from 'redis'; via import map { "redis": "npm:@redis/[email protected]" } 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.

from deno.

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

from deno.

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 #23879). Instead do this and it will make things work:

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

from deno.

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.

/// <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);

from deno.

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.

from deno.

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.

from deno.

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

from deno.

@nayeemrmn this may be related, I upgraded to v1.43.5 from v1.43.1, and now, detected types from:
import { Tokenizer } from "npm:[email protected]"
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?

from deno.

@osddeitf Yes, I believe it should

from deno.

from deno.

@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?

from deno.

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

from deno.

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

from deno.

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

from deno.

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

from deno.

@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.

from deno.