Repository navigation
I want to write explicit .ts file extension in typescript project, and let the compiled file to have .js extension. #55346
Description
🔍 Search Terms
explicit .ts file extension
✅ Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Add a config option to write explicit .ts file extension in typescript project, and let the compiled file to have .js extension.
📃 Motivating Example
It feels wrong to import .ts file as .js file in typescript project.
💻 Use Cases
-
What do you want to use this for?
I want to write explicit
.tsfile extension in typescript project, and let the compiled file to have.jsextension. -
What shortcomings exist with current approaches?
It feels wrong to import
.tsfile as.jsfile in typescript project. -
What workarounds are you using in the meantime?
Write
.jsfile extension in typescript project.
Activity
olivermrose commentedon Aug 13, 2023
https://www.typescriptlang.org/tsconfig#allowImportingTsExtensions
xieyuheng commentedon Aug 13, 2023
xibread That is only for
--noEmitor--emitDeclarationOnly.MartinJohns commentedon Aug 13, 2023
You wrongly checked this point. And the team has stated over and over and over again that they won't do import path rewriting.
xieyuheng commentedon Aug 13, 2023
Martin Johns (@MartinJohns) An new option will not change the runtime behavior of existing JavaScript code, because existing JavaScript code are not using this new option.
Importing TypeScript file with
.jsextension, is importing non existing file in TypeScript.It is much worse then "doing import path rewriting" in TypeScript.
xieyuheng commentedon Aug 13, 2023
Without "import path rewriting", a TypeScript developer must either
Importing non exiting files using
.jsextension.Importing files without extension, thus the generated files can not be use by the browse directly.
The developer must use another tool to transform the files to use them in the browse.
fatcerberus commentedon Aug 13, 2023
This exact discussion has been had a million times and the response from maintainers is always the same: TS is never going to rewrite import specifiers; in all cases you have to write the import that will work at runtime.
fatcerberus commentedon Aug 13, 2023
Duplicate of #49083
#49083 (comment)
MartinJohns commentedon Aug 14, 2023
Just FYI, you're importing modules, not files. Just very often the modules are provided by local files.
xieyuheng commentedon Aug 14, 2023
Thanks for the replies, I will try esbuild and deno to use
.tsas the file extension.fatcerberus commentedon Aug 14, 2023
This is such a great observation. It's something you don't think about in day-to-day coding and when you do, it seems like it's just splitting hairs, but the distinction is exactly what makes the prospect of import path rewriting such a huge can of worms.
xieyuheng commentedon Aug 14, 2023
Isn't JavaScript has one module one file?
MartinJohns commentedon Aug 14, 2023
Xie Yuheng (@xieyuheng) Modules don't have to be files. They just usually are. And the files don't even have to be JavaScript code, e.g. NodeJS allows you to load modules written in C.
In the end it depends on the used module loader and the configuration / implementation. I could decide to import from
a.js, and the loader decides to retrieve the module fromsomethingelse.js.xieyuheng commentedon Aug 21, 2023
This little missing feature means that
you not only need to use
tscto transpile to js files,but also always need a bundler to resolve modules.
This is why Svelte moved away from TypeScript to JSDoc.
Such a move is unimaginable for me before I heard Svelte did that.
Now I am imagining that, as well as many other frontend developers.
I wish the team and people here can think about this for a while,
instead of just shutting this down.
RyanCavanaugh commentedon Aug 21, 2023
I assure you we've thought about this for much longer than you think we have