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