Skip to content

New Option for allowImportingTsExtensions #53316

@WillsterJohnson

Description

@WillsterJohnson

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 .ts extensions in import/export and requires noEmit or emitDeclarationOnly
  • false - has no effect; disables this option
  • "iKnowWhatImDoing" - permits the use of .ts extensions 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs More InfoThe issue still hasn't been fully clarified

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions