-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Description
Suggestion
🔍 Search Terms
allowImportingTsExtensions, allow importing ts extensions, emit, noEmit, emitDelcarationOnly, emit declaration only,
✅ Viability Checklist
My suggestion meets these guidelines:
- 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 TypeScript's Design Goals.
- Possibly would disagree with goal 4 depending on the exact meaning of "clean, idomatic, recognisable"
- Feature would have the user explicitly state they don't want valid JS (eg., as with omitting file extension completely, which is currently a valid syntax for emitting JS, and is more implicit)
⭐ Suggestion
{
"compilerOptions": {
"allowImportingTsExtensions": "iKnowWhatImDoing"
}
}TypeScript will now happily emit JavaScript when using this option for allowImportingTsExtensions.
true- permits the use of.tsextensions in import/export and requiresnoEmitoremitDeclarationOnlyfalse- has no effect; disables this option"iKnowWhatImDoing"- permits the use of.tsextensions in import/export
📃 Motivating Example
For developers working with suitably up-to-date bundlers, the import path is purely a developer-experience convienience; the bundler will wipe it out when it bundles the application.
What's a better DX that grabbing foo/myFile.ts by asking for foo/myFile.js? Straight-up asking for the file as it appears on disc; with a .ts extension.
With this new option, any developer with a drop of experience working with a bundler (and of course with TypeScript) can get set up for a seamless TypeScript experience, one in which "JavaScript" is nothing more than subset of TS syntax.
💻 Use Cases
A significant number of projects, perhaps even the majority, use some kind of bundler.
These bundlers can accept plugins and make sense of almost anything you throw at them if there's a plugin to deal with it.
Many bundlers already know what to do with .ts files; hand them off to the relevant TypeScript plugin.
Bundlers don't emit require or import for local files; they bundle them.
All this adds up to mean that a developer who is using a bundler can reasonably expect it to handle import ? from "*.ts", the only barrier is TypeScript's refusal to emit that code.
There is no workaround; this feature cannot be emulated without forking TS and implementing it.