Deno•15mo 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:

npm:

specifier (i.e.

npm:vite

npm:vite

), if it has type definitions that reference another npm package (i.e.

esbuild

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

npm:vite@5.4.8

as well as

npm:vite@6.0.0-beta.2

npm:vite@6.0.0-beta.2

and both of them don't load the types of

esbuild

esbuild

when importing.

i don't have this issue when importing it from esm.sh, though. and if i manually add

esbuild

esbuild

to the

imports

imports

in my

deno.json

deno.json

, it works too. but not if i directly import from

npm:vite

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

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"
  }
}

{
  "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

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.
  },
});

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.
  },
});

marvinh.•10/7/24, 8:57 PM

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

hewlothereOP•10/7/24, 8:58 PM

thank you!

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

hewlothereOP•10/7/24, 9:10 PM

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

@types/node

as a (dev) dependency in my

package.json

package.json

, if i want deno to use those types in

compilerOptions.types

compilerOptions.types

, is the correct thing to do this?

deno.json

deno.json

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

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

package.json

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"
    }
}

Hhewlothere heya, sorry for another message - i'm going to reply to the github issue soon, a...

marvinh.•10/7/24, 9:12 PM

Deno ignores the

types

types

field in

compilerOptions

compilerOptions

, see https://docs.deno.com/runtime/reference/ts_config_migration/#ts-compiler-options

hewlothereOP•10/7/24, 9:13 PM

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.•10/7/24, 9:13 PM

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

hewlothereOP•10/7/24, 9:14 PM

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

marvinh.•10/7/24, 9:14 PM

in that case it sounds like the

@types/node

@types/node

thing isn't working because the

NodeJS

NodeJS

namespace is defined in that.

marvinh.•10/7/24, 9:16 PM

I'm curious why you need to set the

types

types

field in the first place. Is something not working without doing that?

hewlothereOP•10/7/24, 9:16 PM

yea. if i open the

index.d.ts

index.d.ts

file for

@types/node

@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.•10/7/24, 9:16 PM

might clash with deno's internal node types

Mmarvinh.I'm curious why you need to set the `types` field in the first place. Is somethi...

hewlothereOP•10/7/24, 9:17 PM

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

Hhewlothere i don't need to, i was just attempting to get rid of these while seeing in what ...

marvinh.•10/7/24, 9:18 PM

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•10/7/24, 9:18 PM

but it's ok

they're not a big deal

Mmarvinh.Can you report an issue for that? It should work out of the box and you shouldn'...

hewlothereOP•10/7/24, 9:18 PM

ah ok. same issue or separate?

Hhewlothere ah ok. same issue or separate?

marvinh.•10/7/24, 9:18 PM

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

hewlothereOP•10/7/24, 9:19 PM

ok, will do

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

hewlothereOP•10/7/24, 10:10 PM

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)

Hhewlothere sorry for another question - is there anything i should do to determine if it's ...

marvinh.•10/7/24, 10:13 PM

If the error ends with

deno-ts(<number>)

deno-ts(<number>)

then the error is coming from the Deno extension. If it ends with

ts(<number>

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.

Mmarvinh.If the error ends with `deno-ts(<number>)` then the error is coming from the Den...

hewlothereOP•10/7/24, 10:15 PM

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.•10/7/24, 10:15 PM

It's only a problem with the language server. If you run

deno check file.ts

deno check file.ts

it shows no errors for me

hewlothereOP•10/7/24, 10:16 PM

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

marvinh.•10/7/24, 10:17 PM

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

hewlothereOP•10/7/24, 10:17 PM

ok, thank you!

Mmarvinh.Can you report an issue for that? It should work out of the box and you shouldn'...

hewlothereOP•10/7/24, 11:55 PM

i think i figured out that the missing node types error only happens if you don't explicitly install

@types/node

@types/node

, because

vite

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

Similar Threads

Similar Threads

Similar Threads