In Brief
You're trying to use victor as if it were an es6 module, but it is not. I see two options:
Let tsc convert your modules to a format like commonjs, in which case tsc will provide necessary glue logic between victor and your code
Or you need to load your application through a module loader that provides the glue.
Detailed Explanation
When I run the latest tsc with the import that you show, the error I get is:
This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.
When I turn on esModuleInterop, then it works just fine. Here is the test code I've used:
import Victor from "victor";
const foo = new Victor(1, 2);
console.log(foo.y);
And the tsconfig.json:
{
"compilerOptions": {
"esModuleInterop": true
}
}
The issue originates due to the fact that when you do import Victor from "victor" you are asking for the value that would be exported through an export default... statement, which is a syntax provided by es6 modules. However, victor does export anything that corresponds to export default.... So something has to bridge the gap. With what I've shown above, when you compile, tsc emits this:
"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
return (mod && mod.__esModule) ? mod : { "default": mod };
};
exports.__esModule = true;
var victor_1 = __importDefault(require("victor"));
var foo = new victor_1["default"](1, 2);
console.log(foo.y);
Note the __importDefault helper function. It is used whenever the TS code wants to access what a module exports as export default... What it does is check whether the module claims to be an es6 module. An es6 module that wants to export a default value is already correctly structured so there's nothing to do if the module is an es6 module. If the module is not an es6 module, then the helper creates a kind of fake module whose default exported value is the value of the original module.
There's an important caveat since you mention "targeting ecmascript modules". If you use, this tsconfig.json:
{
"compilerOptions": {
"esModuleInterop": true,
"module": "es6"
}
}
Then the emitted code is:
import Victor from "victor";
var foo = new Victor(1, 2);
console.log(foo.y);
Note that there is no longer any helper function. It is up to the module loader which will load the modules for your application to provide the same logic as provided by __importDefault. If I rename the file to have the mjs extension and run:
$ node --experimental-modules test.mjs
I get this output:
(node:18394) ExperimentalWarning: The ESM module loader is experimental.
2
When using Node with the experimental module support, it provides the same functionality as __importDefault.
When you just use allowSyntheticDefaultImports without using esModuleInterop you are telling the compiler to assume that there will be something in your toolchain that will do the work of __importDefault. So the compiler does not provide a helper. It allows the compilation to proceed, but you are responsible later to use a module loader that will perform the same work as __importDefault.
