`jsr:` specifiers are not installed into `node_modules` (unlike `npm:`)

[Shadowner]

Version: Deno 2.7.12, Linux.
deno install populates node_modules/ with npm: specifiers but not jsr: ones. JSR packages go only to the global cache at ~/.cache/deno/, this holds for both "nodeModulesDir": "auto" and "manual".

Any Node-based tool that walks standard module resolution into a Deno source file (tsc, svelte-check, Vite, TS language server) fails on the jsr: import. In a Deno-backend + Node-frontend monorepo a single unresolved JSR specifier produces a large number of downstream implicit-any errors

I've found some related issues #26138 #26772

Reproduction

I've made a small reproduction here : https://github.com/Shadowner/Deno-Node-JSR-Issue

Excpected

Both specifiers resolve, or at minimum jsr: and npm: behave the same way under nodeModulesDir

What could be done

Make so that "nodeModulesDir": "auto" | "manual" for jsr: specifiers the same way it does for npm:, create a top-level node_modules/@scope/pkg symlink (or directory) mirroring the alias users write in source (@std/ulid, not @jsr/std__ulid)
That single change makes mixed-runtime type consumption work under every standard node-resolution-based tool

I didn't find any workaround other than creating a script that creates those symlink to prevent this error, I'm open to any solution cleaner than doing a script

[dsherret]

If you want them to be in a node_modules folder, then you probably want to define your jsr deps in a package.json:

{
  "dependencies": {
    "@std/ulid": "jsr:^1.0.0",
    "valibot": "^1.1.0"
  },
}

That's sugar for:

{
  "dependencies": {
    "@std/ulid": "npm:@jsr/@std__ulid@^1.0.0",
    "valibot": "^1.1.0"
  },
}

The "imports" in a deno.json is actually just an import map so it will map those jsr deps to https specifiers and it only installs npm packages to the node_modules folder. If you want to download jsr deps via the npm compat layer, then it's possible to do this only in a deno.json like so:

{
  "imports": {
    "@std/ulid": "npm:@jsr/std__ulid@^1.0.0",
    "valibot": "npm:valibot@^1.1.0"
  },
  "nodeModulesDir": "auto"
}

[Shadowner]

Yes it works with the package.json, didn't thought of it, it doesn't solve the problem for a deno first project though

However the deno.json mapping doesn't work, deno install the package under node_modules/@jsr/std__ulid, but the sources still writes import { ulid } from "@std/ulid", that rename only lives in deno import map, which tsc doesn't read from the Node side @std/ulid that is still unresolvable

But thank's for the package.json fix that is way cleaner than my scripting hack !

[dsherret]

However the deno.json mapping doesn't work, deno install the package under node_modules/@jsr/std__ulid, but the sources still writes import { ulid } from "@std/ulid", that rename only lives in deno import map, which tsc doesn't read from the Node side @std/ulid that is still unresolvable

It should probably use the key of the import map and write it under node_modules/@std/ulid if there's no collisions with anything in a package.json. I think right now it just uses the package name.

[Shadowner]

Yes, right now deno just use the package name, which create the incorrect node_modules/@jsr/std__ulid instead of node_modules/@std/ulid (tried with a renamed alias)

Using the import map key might create another problems where some people map ulid to npm:@jsr/std__ulid@^1.0.0 which wont materialise the correct node_modules/@std/ulid but node_modules/ulid folder, which could be a pain to debug (but better than using the package.json and continuing to be deno first)