HewloThere
HewloThere•2mo 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.
marvinh.•2mo ago
That sounds like a bug. I've filed an issue for it https://github.com/denoland/deno/issues/26055
HewloThere
HewloThereOP•2mo 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.
marvinh.•2mo ago
HewloThere
HewloThereOP•2mo 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.
marvinh.•2mo ago
oh maybe our docs are wrong, I just saw the earlier table
HewloThere
HewloThereOP•2mo ago
if i'm getting "Cannot find namespace 'NodeJS'." errors, is there any fix in deno?
marvinh.
marvinh.•2mo 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?
HewloThere
HewloThereOP•2mo 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.
marvinh.•2mo ago
might clash with deno's internal node types
HewloThere
HewloThereOP•2mo 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
No description
marvinh.
marvinh.•2mo 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
HewloThere
HewloThereOP•2mo ago
but it's ok 🙂 they're not a big deal ah ok. same issue or separate?
marvinh.
marvinh.•2mo ago
separate one would be better as I'm not 100% certain that these two are related.
HewloThere
HewloThereOP•2mo 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.
marvinh.•2mo 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.
HewloThere
HewloThereOP•2mo 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.
marvinh.•2mo ago
It's only a problem with the language server. If you run deno check file.ts it shows no errors for me
HewloThere
HewloThereOP•2mo ago
ah ok i see. so report it on the vscode deno repo? or main deno repo?
marvinh.
marvinh.•2mo ago
Doesn't matter which one you pick. The Deno repo gets more eyeballs though.
HewloThere
HewloThereOP•2mo 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