Typescript: Remove "An import path cannot end with a '.ts' extension" check (rewriting out-of-scope)

[ashmind]

Search Terms

"An import path cannot end with a '.ts' extension"
Relevant: #27481 (question, but this one is a proposal)

Suggestion

I would like check "An import path cannot end with a '.ts' extension" to be removed. Note that that any extension transformations are out of scope for this -- having .ts as-is in compiled code is acceptable.

Use Cases

I would like to always use explicit extension in imports as it is consistent with ESM import behavior in both browser and node, and also teaches the right things to others. In the same way LESS uses .less when importing, and Webpack and some other cases analyze imports based on extensions.

This aligns with TypeScript Design Goal 6: Align with current and future ECMAScript proposals and avoids Non-Goal 7 of behavior that is likely to surprise users (people familiar with imports but not TypeScript expect extensions).

I don't mind that extensions are not rewritten as I already have a babel step to add .js extension, and in some cases it needs to be .mjs, which will probably be covered by #18442 anyways.

This matches Non-Goal 4 by not expecting TypeScript to be an end-to-end pipeline (bundling or Babel rewrite will sort .ts).

I know I can use .js but it is non-standard and very confusing to have in source, so for now I prefer not using extensions and rewriting to .js post-compile.

Examples

New

import test from './test.ts'; // works, no warnings

compiles to

// can be rewritten by a babel plugin for now or later when #18442 is implemented
// does not matter at all if using a bundler
import test from './test.ts';

Existing

import test from './test'; // also works, same as now (though I'll use an eslint warning for this)

compiles to

import test from './test'; // same as now

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[MicahZoltu]

This would enable me to update my JS-extension-adding TSC transformer such that it accepts a compiler option for "target file extension" and automatically rewrites any import targeting .ts to target the configured extension (e.g., .mjs or .js) and it would also allow the code to run in ts-node or any other pure-TS environment (e.g., deno). This change would allow my transformer to be much more robust (at the moment it treats everything with a . in the path as "not eligible for transformation") by giving me something I can explicitly target that also makes sense.

[DanielRamosAcosta]

Yeah, this would be great for Deno's development experience and opens the possibilty to write code for both Deno and Node 👏

[alextes]

Note that the linked question ( #27481 ) had dozens of upvotes.

I'd guess that as deno grows the number of people that get false-positives for deno imports will also grow.

[xiaoxiangmoe]

We can use import { identity } from './identity.util.ts' in deno, in parcel, in vite and in webpack.

[timreichen]

Since there is more discussion going on here I link to my issue as a copy.
There I suggested to have the suffix mandatory and a flag --noImplicitSuffix (default: false) that can be set for older projects to work as before.