Closed zolex closed 2 years ago
@zolex Thanks for reporting this. This change is intentional, and was made specifically to support the TypeScript compiler. The full extension path is expected — it’s required for ES modules which don’t implicitly assume a js extension like commonjs does. The TypeScripts compiler expects js extensions and not ts extensions because the compiler does not manipulate import paths: https://www.typescriptlang.org/docs/handbook/esm-node.html. The TypeScript team may reevaluate this in 4.9.
I suspect you're using something other than the TypeScript compiler, such as webpack and ts-loader, to compile your TypeScript code? https://github.com/TypeStrong/ts-loader/issues/1383.
@andrewbeckman ran into this as well and reported it in https://github.com/tatethurston/TwirpScript/issues/192. Given this rough edge, I'm open to reevaluating this.
This could look like the following:
.js
extension for TS. Browser builds like webpack accept ESM without the full extension, so this would only prevent users from running TwirpScript server side as ESM (type: "module" in package.json). I suspect this is an acceptable tradeoff until the TS team better aligns with the rest of the JS ecosystem, and I can expose a config option for the current behavior if anyone requests it.That's interesting, thanks for the detailed answer.
Our Frontend team is using gatsby, do you know how to address this issue here?
@zolex I've published https://github.com/tatethurston/TwirpScript/releases/tag/v0.0.64 with the changes I mentioned above. This should "just work" for you -- let me know if you encounter any issues.
Thanks man, I'll ask our responsible dev on monday to see if it solves the issues.
since version 0.0.61 when ProtoScript is used by twirpscript to generate typescript code, the imports of the messages from the services are broken:
it outputs .pb.ts files but the import statements are .pb.js
generated files:
import statements before 0.0.61
import statements since 0.0.61