I want to write explicit `.ts` file extension in typescript project, and let the compiled file to have `.js` extension.

[xieyuheng]

🔍 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

1. What do you want to use this for?

   I want to write explicit .ts file extension in typescript project, and let the compiled file to have .js extension.

2. What shortcomings exist with current approaches?

   It feels wrong to import .ts file as .js file in typescript project.

3. What workarounds are you using in the meantime?

   Write .js file extension in typescript project.

[olivermrose]

https://www.typescriptlang.org/tsconfig#allowImportingTsExtensions

[xieyuheng]

@xiBread That is only for --noEmit or --emitDeclarationOnly.

[MartinJohns]

• This wouldn't change the runtime behavior of existing JavaScript code

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]

@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 .js extension, is importing non existing file in TypeScript.

It is much worse then "doing import path rewriting" in TypeScript.

[xieyuheng]

Without "import path rewriting", a TypeScript developer must either

1. Importing non exiting files using .js extension.

2. 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]

Importing TypeScript file with .js extension, is importing non existing file in TypeScript.

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]

Duplicate of #49083
#49083 (comment)

[MartinJohns]

1. Importing non exiting files using .js extension.

Just FYI, you're importing modules, not files. Just very often the modules are provided by local files.

[xieyuheng]

Thanks for the replies, I will try esbuild and deno to use .ts as the file extension.

[fatcerberus]

Just FYI, you're importing modules, not files. Just very often the modules are provided by local files.

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]

Isn't JavaScript has one module one file?

[MartinJohns]

@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 from somethingelse.js.

[xieyuheng]

This little missing feature means that
you not only need to use tsc to 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.