Remove "An import path cannot end with a '.ts' extension" check (rewriting out-of-scope) · Issue #38149 · microsoft/TypeScript (original) (raw)

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: