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:

• 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, etc.)
• 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.

[matthew-dean]

I came here to the same. It's strange / unpleasant that TypeScript doesn't allow an .ts extension for imports, especially since the import spec will require extensions in-browser (AFAIK?). I'm working on a transpilation language that uses .ts imports, and ideally, I want to pass imports as they are, and specify (in my language) that .js or .ts must be explicit. I can work around this, but I was searching today about how to turn this error off.

[ljharb]

@matthew-dean to be clear, nothing requires extensions except node’s native ESM, because extensions don’t even exist in the browser. Browsers use URLs, and there’s no reason your asset URLs have to 1:1 match filenames on a filesystem.

[MicahZoltu]

@ljharb Browsers require an exact path match, and TypeScript outputs .js files when transpiling. So unless you have some build-time script that will strip extensions from files on disk, a server-side script (not available in all environments like IPFS or local filesystem) that transform requests, or you have a module loader running in the browser that transforms requests, loading fruit/apple will not resolve to anything since only fruit/apple.ts and fruit/apple.js exist.

[ljharb]

You’re exactly right - but I’ve yet to encounter a system where one of those things isn’t pre-existing or trivial to add.

[MicahZoltu]

Stripping extensions from files on disk makes them not able to load automatically in the proper editor or have proper syntax highlighting auto-detect.

Server side script is impossible for IPFS, S3, or any other static file hosting solution.

Module loaders are what we are trying to avoid here, they are bulky and add complexity to the project and debugging.

All of my projects these days are hosted via static file hosts, and I have gone down the runtime module loader path and it is not pretty.

[piranna]

I think Typescript imports should have (be forced?) a .ts extension, and when transpiled, a .js is being set instead. It's just a change in a string...

[Jamesernator]

Just to note something, one reason that this isn't as trivial to support as it seems is because of the behaviour with dynamic import. In order to support dynamic import correctly, a transform would have to be created that correctly identifies package local files from global files (e.g. in Deno, even if you compile to .js, you still need to be able to import .ts from the web).

While this isn't super super difficult, without a lot of decisions on when to apply rules, or providing a large amount of configuration so that people can create these rules themselves it becomes difficult to reason about such behaviour.

Having said this I'd still generally be supportive of allowing .ts rather than requiring the extension to be the same as the output target. It's currently kinda painful for generating multiple builds as TypeScript doesn't support this sort've thing directly.

The TSC team has mentioned in the past it doesn't want TypeScript to be an end-to-end build tool, but it could still offer more for processing TypeScript specific things like this itself.

Interestingly if TypeScript simply supported .ts in the import, it would actually be possible to map the .ts OUTSIDE of TypeScript's compiler, via tools such as import maps or "imports" in Node.js. These sort've solutions would actually still have import foo from "./foo.ts"; inside the .js files, but they're actually fairly trivial to map away in a way that also works with dynamic import.

[tracker1]

@Jamesernator absolutely... of course, the tsc could have an option to either ignore or place an (outdir)/_cache/http/host/path/to/*.js as an output option... Or just ignore urls starting with http, https and // leaving it to other tools to deal with.

That said, if you are importing ./foo.ts then proceed to load and output to ./foo.js, then it's not too much to ask that you update references to ./foo.ts to ./foo.js... and do similar for caching http(s) references. This would absolutely make the most sense and be the least friction in practice as options. Yeah, it's easier to dismiss it because node will assume .js extension, but the browser loading doesn't support it either. If you want to support targeting a modern browser, then matching and including the extension from input to output makes more sense, not less.