I\'m trying to use the victor.js library in a TypeScript project (3.0.1) and I\'m having real heartache trying to import and use it. I\'ve installed it from npm along with it\'s
I see there has already been excellent answers but would like to add this shorter answer.
Error message: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.ts(2497)
I had this problem with importing when moving from es5 to es6 (and javascript to typescript) when converting my own javascript file to typescript.
Importing like import * as File from "./MyFile"
in OtherFile.ts .
In MyFile.ts file I had export = {funcName}
at the end.
The solution was to remove =
like this export {funcName}
from the MyFile.ts file.
(Hope this helps someone, first time trying to make an answer for a an error/problem)
I feel your heartache, In that I spent a large amount of time debugging various errors on how to write typescript definition files for existing javascript modules and finally got to what I thought was the final hurdle when I got stuck on the same error:
This module can only be referenced with ECMAScript imports/exports by turning on the 'allowSyntheticDefaultImports' flag and referencing its default export
The javascript in question here:
module.exports = class AthenaExpress { ...more code.. }
tsconfig.json
for the compiling/"Working version" 1:
{
"compilerOptions": {
"outDir": "dist/",
"sourceMap": true,
"noImplicitAny": true,
"module": "commonjs",
"target": "es6",
"jsx": "react"
},
"baseUrl": "./src",
"include": [
"**/*"
],
"exclude": [
"node_modules"
]
}
"Working version" of the d.ts
file with some import differences 2:
declare module 'athena-express' {
import * as aws from "aws-sdk";
interface ConnectionConfigInterface {
aws: typeof aws,
s3: string,
getStats: boolean
}
interface QueryResultsInterface {
Items: any[],
DataScannedInMB: number,
QueryCostInUSD: number,
EngineExecutionTimeInMillis: number,
Count: number,
}
interface QueryInterface {
sql: string,
db: string,
}
type QueryResult = QueryResultsInterface
interface AthenaExpressInterface {
new: (config: ConnectionConfigInterface) => any,
query: (query: QueryInterface) => QueryResult,
}
class AthenaExpress {
new: (config: ConnectionConfigInterface) => any;
constructor(config: ConnectionConfigInterface);
query: (query: QueryInterface) => QueryResult;
}
}
Version of the d.ts
file that received the same error, even when esModuleInterop
was enabled, I also fiddled around with module
and target
to no avail. With import statement differences 3:
import * as aws from "aws-sdk";
interface ConnectionConfigInterface {
aws: typeof aws,
s3: string,
getStats: boolean
}
interface QueryResultsInterface {
Items: any[],
DataScannedInMB: number,
QueryCostInUSD: number,
EngineExecutionTimeInMillis: number,
Count: number,
}
interface QueryInterface {
sql: string,
db: string,
}
type QueryResult = QueryResultsInterface
interface AthenaExpressInterface {
new: (config: ConnectionConfigInterface) => any,
query: (query: QueryInterface) => QueryResult,
}
declare class AthenaExpress {
new: (config: ConnectionConfigInterface) => any;
constructor(config: ConnectionConfigInterface);
query: (query: QueryInterface) => QueryResult;
}
export = AthenaExpress
notes:
The definition file location and the file I was trying to get working with the definition:
tree src/backend/js
src/backend/js
├── athena-express.d.ts
└── helloworld.ts
tsc
seemed to compile without complaintimport {AthenaExpress} from "athena-express";
import * as AthenaExpress from "./athena-express";
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.
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
.