Can not import JSON config file if the config file specifies jsxImportSource

[lucacasonato]

// main.ts
import config from "./deno.json" assert { type: "json" };
const obj = { config };
export default obj;

// deno.json
{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "preact"
  },
  "importMap": "./import_map.json"
}

// import_map.json
{
  "imports": {
    "preact/": "https://esm.sh/[email protected]/"
  }
}

$ deno run -A main.ts
error: Loading unprepared module: file:///tmp/jsx_config_issue/deno.json

I think what is happening is that the config file is stored in the module graph as some sort of special entry, which is causing this weird behaviour.

[kitsonk]

We need to handle scanning for pragma better. We shouldn't do it in JSON files and tighten the scan.

[lucacasonato]

I should clarify that this file that I am importing through the import is actually also the config file for the project. It's a file in the module graph, and the config file for the module graph at the same time (I hope that makes sense).

[kitsonk]

Understood. Actually that might be the problem, in the sense when we have jsxImportSource we inject the config file as a synthetic module to be able to resolve the jsx runtime. That then occupies the slot and then it cannot exist as a JSON module.

Either way it is a deno_graph bug I think.

[nayeemrmn]

Ref https://github.com/denoland/deno_graph/issues/167

[kitsonk]

Looking into it, setting "types" in the compiler options would also cause this behaviour. Basically, whenever there is some that is rooted to the config file, CLI synthetically imports it with the config file as the base. This causes the graph to add it as a synthetic module and then subsequently, when the JSON import is identified, the graph says "oh, I already have that, so I will just ignore it". Since synthetic modules cannot be "loaded", it results in the error of the unprepared module.

[nayeemrmn]

As I alluded to in https://github.com/denoland/deno_graph/issues/167#issuecomment-1200089544, config files shouldn't be in the same specifier pool as modules, we should factor that out to a separate set of roots

[kitsonk]

I understand what you alluded to.