4 ms·
Hey! Not sure how modern your codebase is, but you can consider the following tsconfig settings: - rewriteRelativeImportExtensions: this will allow you to writ
by gauben 2y ago
Hey! Not sure how modern your codebase is, but you can consider the following tsconfig settings:
- rewriteRelativeImportExtensions: this will allow you to write `import foo from './foo.ts'` and have tsc transform it to `import foo from './foo.js'`
- erasableSyntaxOnly: this will error on non "erasable" syntax, that is, TypeScript code that has a runtime output (e.g. enums)
With these two settings enabled, you'd be able to run TypeScript code directly with Node: `node src/index.ts`, and cut boot up time substantially
- hombre_fatal 2y agoTo add, those are the recommended tsconfig.json settings in Node's docs on native TS stripping. Here are the rest: https://nodejs.org/api/typescript.html#type-stripping https://nodejs.org/api/typescript.html#type-stripping
- WorldMaker 2y agoAlso there are eslint rules older than erasableSyntaxOnly that can also be useful in doing a "rip-the-bandaid-off-refactor" using all the lint warnings/warnings-as-errors to add extensions everywhere in the case where your brownfield also needs to be a version or two behind on Typescript.
- hakkotsu 2y agoWhile `rewriteRelativeImportExtensions` works for frontend applications, it has a significant limitation: it doesn't fix declaration files (.d.ts), which is problematic when developing libraries or public packages. I created a small tool to address ESM + TypeScript issues that the tsc doesn't handle: https://github.com/2BAD/tsfix https://github.com/2BAD/tsfix
- tsarchitect 2y agoHow about for aliases? import foo from '@Schemas/foo.ts' won't work since it is not a 'RelativeImport'. Is there a fix for this use case?