deno check error resolving package config for npm react jsx-runtime

[lrowe]

While importing the npm:@types packages as per #16653 silences errors from the language server when running deno check I see the following error:

% deno check index.tsx
Check file:///Users/lrowe/scratch/react-server-deno/index.tsx
error: Uncaught Error: Error resolving package config for 'npm:react@18.2.0/jsx-runtime': [ERR_PACKAGE_PATH_NOT_EXPORTED] Package subpath './jsx-runtime' is not defined by "exports" in '/Users/lrowe/Library/Caches/deno/npm/registry.npmjs.org/react/18.2.0/package.json' imported from '/Users/lrowe/Library/Caches/deno/npm/registry.npmjs.org/react/18.2.0/'
    at <anonymous> (ext:deno_tsc/99_main_compiler.js:592:28)

However in react's package.json an entry for './jsx-runtime' exists:

  "exports": {
    ".": {
      "react-server": "./react.shared-subset.js",
      "default": "./index.js"
    },
    "./package.json": "./package.json",
    "./jsx-runtime": "./jsx-runtime.js",
    "./jsx-dev-runtime": "./jsx-dev-runtime.js"
  },

Files to reproduce:

index.tsx:

// See: https://github.com/denoland/deno/issues/16653
import type {} from "npm:@types/react@18";
import type {} from "npm:@types/react-dom@18";

import React from "npm:react@18";
import { renderToString } from "npm:react-dom@18/server";

function Hello() {
  return <div>Hello world!</div>;
}

console.log(renderToString(<Hello />));

deno.json:

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "npm:react@18"
  }
}

% deno --version      
deno 1.31.2 (release, aarch64-apple-darwin)
v8 11.0.226.19
typescript 4.9.4

[KyleJune]

I've encountered this same issue. It is preventing me from switching from using esm.sh to using npm specifiers. Are there any plans to fix this issue anytime soon?

error: Uncaught Error: Failed resolving package config for 'npm:react@18.2.0/jsx-runtime': [ERR_PACKAGE_PATH_NOT_EXPORTED] Package subpath './jsx-runtime' is not defined for types by "exports" in '/home/kyle/.cache/deno/npm/registry.npmjs.org/react/18.2.0/package.json' imported from '/home/kyle/.cache/deno/npm/registry.npmjs.org/react/18.2.0/'
    at <anonymous> (ext:deno_tsc/99_main_compiler.js:676:28)

[nayeemrmn]

This is just #20455, which is on the roadmap but not currently being worked on.

The following workaround doesn't work:

// @deno-types="npm:@types/react@18"
import React from "npm:react@18";
// @deno-types="npm:@types/react-dom@18/server"
import { renderToString } from "npm:react-dom@18/server";

function Hello() {
  return <div>Hello world!</div>;
}

console.log(renderToString(<Hello />));

because it doesn't apply to the "jsxImportSource": "npm:react@18" in your compiler options. There's no way of tagging that one.

[dsherret]

What about adding a "jsxImportSourceTypes" : "npm:@types/react@18" option? I think that would be better than #20455 for the reasons I outlined in that issue and you'd be able to specify types when there's a version mismatch between the @types package and the actual package. Another benefit is it's right beside where you define jsxImportSource so that makes it easier to update both at the same time.

[KyleJune]

That would be better but I'm guessing people will regularly miss that they need to set that types option too. Then they'd only find out if they google the error and find issues like this one.

Then we still have the problem that you'll need to add a bunch of these comments in any files that import react or other dependencies that have separate types.

// @deno-types="npm:@types/<package>"

I feel like it would be better to have a version mismatch in some cases than to have no types at all. I'd rather only have to add those comments in the case there is a mismatch issue than to need them for most modules.

The way esm.sh picks the types to use seems to just work the way you would expect it to. I don't have to manually set or override types for any of my esm.sh dependencies.

[nayeemrmn]

A nice general solution would be to extend our compilerOptions::types field (which is already incompatible with tsc) to support type associations:

{
  "compilerOptions": {
    "types": [
      "./types.d.ts",
      "https://deno.land/x/pkg@1.0.0/types.d.ts",
      { "target": "https://deno.land/x/some_untyped_module/", "types": "npm:@types/some-untyped-module/" },
      { "target": "npm:react@18", "types": "npm:@types/react@18" },
      { "target": "npm:react@18/", "types": "npm:@types/react@18/" }
    ]
  }
}

This would be yet another, but meaningfully distinct way of adding types to untyped modules. In order of priority:

1. // @deno-types at the import site.
2. { "target": "npm:react@18/", "types": "npm:@types/react@18/" } in project config. (new)
3. /// <reference types="..." /> in the module itself.
4. X-Typescript-Types: ... header that the module is served with.

It would satisfy the need to out-scope "jsxImportSource", you won't need to write duplicate @deno-types directives and this seems like a sensible configuration item to have independently of this issue.

It's comparable to adding the @types/react entry to your package.json.

[dsherret]

@nayeemrmn seems complex. That would require keeping the react version in sync in 5 places instead of once for react and once for @types/react.

[KyleJune]

I like the idea of it just being something you add to deno.json. although if we add it to the types array, it would be nicer if we could just add the string "npm:@types/react@18.0.2" without having to specify a target or have 2 entries like you do where one has a trailing slash. In package.json you would just add the types to your list of dependencies without having to specify they are the types for react.

Ideally we would either not have to specify types or just have one place to specify them for the whole project.

[nayeemrmn]

t would be nicer if we could just add the string "npm:@types/react@18.0.2"

That's a good idea, since npm: specifiers are graced it makes sense to allow that. If npm:@types/foo is detected in that types field, it's used for untyped npm:foo/<path> specifiers:

{
  "compilerOptions": {
    "types": [
      "./types.d.ts",
      "https://deno.land/x/pkg@1.0.0/types.d.ts",
      // Will be used for any `npm:react@18.x.x/*`
      "npm:@types/react@18"
    ]
  }
}

@dsherret WDYT?

[KyleJune]

The only additional thing I would want is for it to be able to work with an import map, that way I could just specify the version there instead of having to update both deno.json and my import map to bump my react version.

I think adding a types array entry like that would be the easiest way to do it as it would get rid of needing to add a bunch of deno-types comments all over your codebase.

[dsherret]

@nayeemrmn I like that too 👍

@KyleJune you can store the import map in a deno.json nowadays (just copy and paste the "imports" and "scopes" properties into the deno.json, delete the "importMap" property in deno.json, then delete the import map file). I don't think we could support this in an import map file because it would be non-standard.

[nayeemrmn]

I assume compilerOptions::types entries are put through the import map, so I think you'd naturally be able to do:

{
  "compilerOptions": {
    "types": [
      "./types.d.ts",
      "https://deno.land/x/pkg@1.0.0/types.d.ts",
      // If this resolves to `npm:@types/react@18`, it will be used for any `npm:react@18.x.x/*`
      "@types/react"
    ]
  },
  "imports": {
    "@types/react": "npm:@types/react@18"
  }
}

Though I wouldn't personally bother if they're in the same file anyway.