I wanted to import a JSON file using ES Modules default import syntax inside my TypeScript application, but...
\nThe settings.json file with the valid JSON content:
\n{\n \"env\": \"production\"\n}Solution
\ntsc --resolveJsonModule --esModuleInterop JSONReader.tsES Modules (ESM), next to other module systems (i.e.: AMD, UMD, and CommonJS), are yet another way of bringing modularity to JavaScript.
\nAlthough we can already declare script as module in modern browsers,\nwe still cannot forget about the almighty module bundlers that allowed bundling JavaScript modules into a single JavaScript file from the very beginning. Nowadays Webpack and Parcel are dominating the space.
\nNodeJS, on the other hand, has embraced modularity from its beginning thanks to the CommonJS syntax. Nevertheless, being able to eventually replace CommonJS with ES Modules and work with one module system only is fascinating.
\nWith that, let's check together whether TypeScript has any tricks up its sleeve to handle ES Modules more gracefully.
\nGenerally speaking, TypeScript is mostly concerned about typechecking, leaving the topics of modularity and bundling to other tools like Webpack, Packer, SystemJS, or AMD.\nHowever, by treating any file with a top-level import or export as a module, it usually does not stand in our way when we try to use ES Modules syntax.
\nFurthermore, depending on the combination of --target, --module, and --moduleResolution flags, TypeScript Compiler knows how to generate appropriate code for CommonJS, AMD, UMD, SystemJS, or ES Modules systems.
Is it going to protest when we try to import a JSON file using ES Modules default import syntax or let it go?\nLet's verify it by creating a simple file JSONReader.ts with the following content.
\nimport settings from \"./settings.json\";\n\nconsole.log(settings.env);As soon as we compile it with tsc JSONReader.ts, we will instantly see the following error:
JSONReader.ts:1:22 - error TS2732: Cannot find module './settings.json'. Consider using '--resolveJsonModule' to import module with '.json' extensionBecause TypeScript Compiler does not tolerate importing JSON files like that out of the box, let's try to get to the bottom of this issue by exploring the possible solutions together.
\nBy shouting with the TS2732 error code, the TypeScript Compiler also gave us a decent hint, suggesting to use the --resolveJsonModule compiler flag.
tsc --resolveJsonModule JSONReader.tsUnfortunately, this advice was not enough. We have immediately come across another error, as shown below.
\nerror TS1259: Module '\"~/prodding-typescript/esm-default-import-json-file/settings\"' can only be default-imported using the 'esModuleInterop' flagBy default, even if the TypeScript Compiler reports a compilation error, it can still emit corresponding JavaScript files (in our case, this is JSONReader.js file).\nIf we try to run it via NodeJS Interpreter like node JSONReader.js, we will get the following error:
~/prodding-typescript/esm-default-import-json-file/JSONReader.js:4\nconsole.log(settings_json_1[\"default\"].env);\n ^\n\nTypeError: Cannot read property 'env' of undefinedBy looking into the content of the JSONReader.js file (presented below), we see that TypeScript Compiler not only has converted ES Modules syntax to CommonJS, but also created an additional default namespace which has caused the above TypeError.
\n\"use strict\";\nexports.__esModule = true;\nvar settings_json_1 = require(\"./settings.json\");\nconsole.log(settings_json_1[\"default\"].env);To fix it, let's follow yet another advice from TypeScript Compiler, this time regarding the --esModuleInterop compiler flag.
tsc --resolveJsonModule --esModuleInterop JSONReader.tsOr to be even more specific, because --esModuleInterop and --allowSyntheticDefaultImports are closely related to each other, we could run it like so:
tsc --resolveJsonModule --esModuleInterop --allowSyntheticDefaultImports true JSONReader.ts After that, all the TypeScript Compiler's errors are gone. If we run the re-generated JavaScript file with node JSONReader.js now, we should see the correct production text in the console.
When we examine this file again (presented below), we should spot a new __importDefault helper function that enables interoperability between CommonJS and ES Modules via the creation of namespace objects for all imports.
\"use strict\";\nvar __importDefault = (this && this.__importDefault) || function (mod) {\n return (mod && mod.__esModule) ? mod : { \"default\": mod };\n};\nexports.__esModule = true;\nvar settings_json_1 = __importDefault(require(\"./settings.json\"));\nconsole.log(settings_json_1[\"default\"].env);That's all there is to it. Before we wrap it up, let's clarify a few things:
\n--resolveJsonModule has been introduced in TypeScript 2.9 and is false by default.\nThis requires the developers to opt-in for this behavior, because loading the JSON files that way may consume lots of memory (underneath the require directive is used).--esModuleInterop has been introduced in TypeScript 2.7 and is also false by default.\nIf you set the --esModuleInterop to true, --allowSyntheticDefaultImports flag will be automatically set to true as well. (In this tutorial we didn't use tsconfig.json yet, but if you were about to create one with tsc --init, the esModuleInterop option will be set to true there)--target flag. This automatically sets the --module to CommonJS, which in turn sets the --moduleResolution to node.\nAll these sane defaults allow us to use the --resolveJsonModule flag, which otherwise would not be possible. Feel free to set the --module or --target to ES6 and verify yourself if you get a TS5070 error code.--esModuleInterop flag. There is an alternative syntax that imports the entire module into a single variable as follows: import * as settings from "./settings.json".