Purpose of "resolveJsonModule"?

Question

The setting I am referencing is shown in the snippet bellow

{
  "compilerOptions": {
    "resolveJsonModule": true,
  }
}

I don't really understand why TS language engineers would add a flag for "resolveJsonModule"? Either an environment supports resolving JSON as module via an import statement (or require() method), or the environment doesn't. Why bother with the extra complexity?

Axiomatic

These may help: 1) typescriptlang.org/tsconfig#resolveJsonModule - says "in Node projects".So should be good. 2) docs.npmjs.com/creating-node-js-modules 3) github.com/microsoft/TypeScript/issues/25400 -Says restarting VSCode/Webstorm if that is your editor (restart cmd in VSCode). Also a comment about esnext - It also infers the use of * rather than specific import appears to be problematic too. 4) You may want to look at this too in relation to * typescriptlang.org/tsconfig#allowSyntheticDefaultImports 5) "include": [ "./**/*", "./**/*.json" ] – Orozco

Answer 1

Context

Historically, Node has included a specialized JSON loader (unrelated to ECMA standards) to allow importing JSON data only in CommonJS mode.

Standardized importing of anything at all (ES modules) is only a relatively recent phenomenon in ECMAScript. Importing text files containing valid JSON, parsed as native JS data ("importing JSON") is described in a proposal that is still only in stage 3.

However, there has been recent movement in regard to implementation of the above mentioned proposal:

• V8 implemented it in 2021 June (Chrome 91+)
• TypeScipt v4.5.0 implemented it in 2021 November
• Deno v1.17.0 implemented it in 2021 December
• Node LTS v16.14.0 implemented it in 2022 February (behind a CLI flag --experimental-json-modules)

---

TypeScript

TypeScript is a static type-checker, but also a compiler (technically a transpiler), and transforms your TS source code syntax into a syntax that is valid JavaScript for the runtime environment you have specified in your TSConfig. Because there are different runtime environments with different capabilities, the way that you configure the compiler affects the transformed JavaScript that is emitted. In regard to defaults, the compiler uses an algorithmic logic to determine settings. (I can't summarize that here: you honestly have to read the entire reference in order to understand it.) Because loading of JSON data has been a non-standard, specialized operation until extremely recently, it has not been a default.

---

Alternatives

All JS runtimes offer alternatives to an import statment for importing of textual JSON data (which can then be parsed using JSON.parse), and none of them require configuring the compiler in the ways that you asked about:

Note: the data parsed from the JSON strings imported using these methods will not participate in the "automatic" type inference capabilities of the compiler module graph because they aren't part of the compilation graph: so they'll be typed as any (or possibly unknown in an extremely strict configuration).

• Browser and Deno: window.fetch
• Deno: Deno.readTextFile
• Node: fs.readFile

Additionally, because all JSON (JavaScript Object Notation) is valid JS, you can simply prepend the data in your JSON file with export default , and then save the file as data.js instead of data.json, and then import it as a standard module: import { default as data } from "./data.js";.

---

Final notes about inferred types:

I prefer to audit the JSON that I'm importing and use my own manually-written types (written either by myself or someone else: imported from a module/declaration file) for the data, rather than relying on the compiler's inferred types from import statements (which I have found to be too narrow on many occasions), by assigning the parsed JSON data to a new variable using a type assertion.

Chalcopyrite

You're killing it with many of your answers. This one is fabulous. Very clear, concise, and well documented. I loved that you included links, especially the one for the TC39 proposal. It takes a good amount of time to write an answer like this. What I gather, is when writing a ECMAS standardized language in its native browser env, it has consequences that affect the handling of the document, the documents mime type, furthermore; A URL has to be used to import the document, and this has further implications, that can cause an undesired and/or confusing URL format. – Axiomatic

So to answer my own question shortly, now that I have been endowed with your the info from your answer: "There are implications for using the setting, but the implications affect the front end. Because I am dealing with a filesystem, and not a URL, I should be okay." – Axiomatic