Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
5 tasks done
ashmind opened this issue Apr 23, 2020 · 13 comments · Fixed by #51669
Closed
5 tasks done
Labels
Fix Available A PR has been opened for this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@ashmind
Copy link

ashmind commented Apr 23, 2020

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
Copy link
Contributor

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
Copy link

DanielRamosAcosta commented May 11, 2020

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

@alextes
Copy link

alextes commented May 13, 2020

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
Copy link
Contributor

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

@timreichen
Copy link

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
Copy link

matthew-dean commented Jan 10, 2021

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
Copy link
Contributor

ljharb commented Jan 10, 2021

@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
Copy link
Contributor

@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
Copy link
Contributor

ljharb commented Jan 13, 2021

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
Copy link
Contributor

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
Copy link

piranna commented Jul 2, 2021

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
Copy link

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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix Available A PR has been opened for this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.