Open treecy opened 5 years ago
If I remember correctly it was because of the way @types/node-int64
were defined. They wouldn't import properly with the standard form (import Int64 from 'node-int64'
) because they don't define a default export. I'll double check and we'll explore a fix.
@kevin-greene-ck Oh, I see! Thank you !
I've opened #155 to update the thrift-server output to imit import =
statements. Doing this for the apache output might be a little harder, but I have not looked at it closely.
I am currently using the Apache Thrift output and also get the Import assignment cannot be used when targeting ECMAScript modules.
error on the import Int64 = require("node-int64");
line in one of the generated files using an i64
variable.
I am also patiently waiting for an update on this one :)
I've just run into this issue. Actually, I'm trying to make use of thrift-typescript on the browser front end. While I can replace the require("node-int64")
in all generated files with a nasty bash find + sed command, I'm still not able to compile the result without Node, so it wouldn't be available in the browser environment. Am I doing something wrong entirely?
I also have this problem.
I change import Int64 = require("node-int64");
to import Int64 from "node-int64";
, that make my next.js
api work
For Int64 the generated code is:
But this syntax is not supported by @babel/plugin-transform-typescript, and I think
should work the same.
I wonder why choosed to use
import =
statement?