HewloThere•3mo ago

Type resolution for modules imported with `npm:` specifier

moved from here: https://discord.com/channels/684898665143206084/684898665151594506/1292948811643224136 if i'm importing something from npm with an npm: specifier (i.e. npm:vite), if it has type definitions that reference another npm package (i.e. esbuild), is it a deno issue or a package issue if the types aren't resolved by deno (at least, the deno vscode extension)? tried with both npm:vite@5.4.8 as well as npm:vite@6.0.0-beta.2 and both of them don't load the types of esbuild when importing. i don't have this issue when importing it from esm.sh, though. and if i manually add esbuild to the imports in my deno.json, it works too. but not if i directly import from npm:vite. if this is to be expected then that's all good, just was wondering if i should report an issue or anything 🙂 actually, it correctly resolves the type (in the vscode extension?) up until i try to look at the types for vite. not sure if it's just flaky, but it seems to only work (until i navigate to the types for vite) if i tell deno to generate a lock file and i have run deno clean? i think? e.g.: deno.json:

{
  "lock": true,
  "imports": {
      "vite": "npm:vite@^6.0.0-beta.2",
      "esbuild": "npm:esbuild@^0.24.0",
      "postcss": "npm:postcss@^8.4.47",
      "rollup": "npm:rollup@^4.22.5"
  }
}

{
  "lock": true,
  "imports": {
      "vite": "npm:vite@^6.0.0-beta.2",
      "esbuild": "npm:esbuild@^0.24.0",
      "postcss": "npm:postcss@^8.4.47",
      "rollup": "npm:rollup@^4.22.5"
  }
}

file.ts

import { build } from 'vite';

await build({
  // stuff
  esbuild: {
    loader: 'tsx', // error is here, but only after i try to look at the types for vite in vscode.
  },
});

import { build } from 'vite';

await build({
  // stuff
  esbuild: {
    loader: 'tsx', // error is here, but only after i try to look at the types for vite in vscode.
  },
});

20 Replies

marvinh.•3mo ago

That sounds like a bug. I've filed an issue for it https://github.com/denoland/deno/issues/26055

HewloThereOP•3mo ago

thank you! heya, sorry for another message - i'm going to reply to the github issue soon, after i attempt to pinpoint the issue a little bit but just had a quick question while i do that. if i have @types/node as a (dev) dependency in my package.json, if i want deno to use those types in compilerOptions.types, is the correct thing to do this? deno.json

{
    "nodeModulesDir": "auto",
    "lock": true,
    "compilerOptions": {
        "types": ["node"]
    },
    "exclude": ["./dist"]
}

{
    "nodeModulesDir": "auto",
    "lock": true,
    "compilerOptions": {
        "types": ["node"]
    },
    "exclude": ["./dist"]
}

package.json

{
    "dependencies": {
        "vite": "^6.0.0-beta.2",
        "esbuild": "^0.24.0",
        "postcss": "^8.4.47",
        "rollup": "^4.22.5"
    },
    "devDependencies": {
        "@types/node": "22.7.4"
    }
}

{
    "dependencies": {
        "vite": "^6.0.0-beta.2",
        "esbuild": "^0.24.0",
        "postcss": "^8.4.47",
        "rollup": "^4.22.5"
    },
    "devDependencies": {
        "@types/node": "22.7.4"
    }
}

marvinh.•3mo ago

Deno ignores the types field in compilerOptions, see https://docs.deno.com/runtime/reference/ts_config_migration/#ts-compiler-options

HewloThereOP•3mo ago

ah i see, sorry i was looking here. probably a bit outdated https://docs.deno.com/runtime/reference/ts_config_migration/#suppling-"types"-in-deno.json

marvinh.•3mo ago

oh maybe our docs are wrong, I just saw the earlier table

HewloThereOP•3mo ago

if i'm getting "Cannot find namespace 'NodeJS'." errors, is there any fix in deno?

marvinh.•3mo ago

in that case it sounds like the @types/node thing isn't working because the NodeJS namespace is defined in that. I'm curious why you need to set the types field in the first place. Is something not working without doing that?

HewloThereOP•3mo ago

yea. if i open the index.d.ts file for @types/node in vscode, the errors go away, but even tho the file has the reference like below at the top, it seems to not resolve:

/// <reference types="node" />

/// <reference types="node" />

marvinh.•3mo ago

might clash with deno's internal node types

HewloThereOP•3mo ago

i don't need to, i was just attempting to get rid of these while seeing in what cases type resolution works/doesn't work

marvinh.•3mo ago

Can you report an issue for that? It should work out of the box and you shouldn't have to fiddle with these things manually

HewloThereOP•3mo ago

but it's ok 🙂 they're not a big deal ah ok. same issue or separate?

marvinh.•3mo ago

separate one would be better as I'm not 100% certain that these two are related.

HewloThereOP•3mo ago

ok, will do sorry for another question - is there anything i should do to determine if it's the vscode extension or deno itself? (wanna make sure i report it in the right repo)

marvinh.•3mo ago

If the error ends with deno-ts(<number>) then the error is coming from the Deno extension. If it ends with ts(<number> then it's coming from vscode's ts server. In your case all the errors in your screenshot are coming from the Deno extension.

HewloThereOP•3mo ago

err sorry if my question was confusing. i was meaning more so, if it is a problem with how deno does module resolution or if it's just a problem with the language server. not sure if same answer? the deno language server is definitely enabled tho

marvinh.•3mo ago

It's only a problem with the language server. If you run deno check file.ts it shows no errors for me

HewloThereOP•3mo ago

ah ok i see. so report it on the vscode deno repo? or main deno repo?

marvinh.•3mo ago

Doesn't matter which one you pick. The Deno repo gets more eyeballs though.

HewloThereOP•3mo ago

ok, thank you! i think i figured out that the missing node types error only happens if you don't explicitly install @types/node, because vite only has it as a dev dependency after installing them, it seems to work. so i don't think the node types needs to be an issue? but the esbuild type resolution issue still happens regardless. i added a comment on the github issue you made earlier with some weird edge cases or whatever i found. not sure if helpful

Type resolution for modules imported with `npm:` specifier

Did you find this page helpful?