-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
allow voluntary .ts suffix for import paths #37582
Comments
After some more research I wonder if that behavior could even be more guided by a compiler option like What are your thoughts on that? |
Read through the above and it seems to boil down to multiple build targets with different file extensions throws a wrench in things when supporting using the file extensions on imports. Where it diverges in my mind, and hopefully @Jack-Works you can illuminate this a bit, is that we'd be importing .ts extensions which would have to be rewritten anyways. |
So... where are we actually at with this? Scattered issues / feature requests don't help, and the confusing (and somewhat untimely) response(s) from official TypeScript members haven't helped me understand how this feature will be implemented (it will have to be, eventually). All I can ascertain is that this is has yet to be resolved. Can someone explain in plain English when and how these multiple issues will be fixed, please? |
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
- TypeScript fails to correctly generate an ESM module with correct line endings - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
…tensions) - TypeScript fails to correctly generate an ESM module with correct file extensions - ref: <microsoft/TypeScript#18442 (comment)> - ref: <microsoft/TypeScript#18442> - ref: <microsoft/TypeScript#37582> - ref: <microsoft/TypeScript#35148>
+1 If I turn on
Allowing |
@tracker1 the reason is historical and it is not a bad one at all only this implementation is done bad the reasoning and concepts are in general well it is a bit like with the ECMASpec it self it is easy to write a good spec but implementation and definition do then end up in something diffrent. The ground concept is the classic resolve algo which is you reference myname.js and it will lookup myname.ts as also myname.d.ts that is the base then the assumption comes in that you can not reference .ts files as this would mean to change existing code eg make it point to .js. when we now want to reference .ts we broke the core concept of TS which is to be a facade over JS that is optional. but now as we used all that we come to the conclusion that referencing .ts would be beneficial if we apply external tooling as that saves us from lookups which are error proune. And now to solve this there are 2 major ways to go and both are none appealing for ts and mirosoft. The Both ways to go are:
But i identified many incremental pathes to update
|
I hope this also allows enforcing the use of extensions as an option so that imports without extensions aren't allowed |
It does not. You might want to track #50153, and if you’re concerned with Deno, see my advice at #51669 (comment). |
To approach this problem from another angle, you may want to consider This is what we've been using to enforce |
If you are compiling TS code to JS code that will run in Node, you should be using |
Just saw #51669–is this really finally fixed?! |
We added this lint rule because we had breakages that we would only see in the production builds (because use The inconsistencies between bundlers allowing no extensions and
Ideal feels like TS should just allow for It seems almost like maybe that's what |
But indeed, TypeScript does show the error about missing file extensions also in the IDE, which is great - thanks for the tip! I needed to do some configuration for this, but it's working. I'll try applying it to those projects, maybe they are just not configured the same way.
I needed to add {
"$schema": "https://json.schemastore.org/tsconfig",
"compilerOptions": {
"lib": ["dom", "dom.iterable", "esnext"],
"module": "NodeNext",
"target": "ESNext",
"moduleResolution": "NodeNext",
"resolveJsonModule": true,
"esModuleInterop": true,
"isolatedModules": true,
"allowJs": true,
"downlevelIteration": true,
"forceConsistentCasingInFileNames": true,
"noEmit": true,
"noFallthroughCasesInSwitch": true,
"skipLibCheck": true,
"strict": true,
"incremental": true,
"noUncheckedIndexedAccess": true
},
"include": [
"**/.eslintrc.cjs",
"next-env.d.ts",
"**/*.ts",
"**/*.tsx",
"**/*.cjs",
"**/*.mjs"
],
"exclude": ["node_modules", "build"]
} |
Yes, because without either this or
This rule is only relevant in |
@andrewbranch it would be really great if TS made it easy to use native ESM without type module, since that package.json flag causes lots of issues with outdated tooling and also causes lots of confusion for new users. |
@ljharb can you expound on that? In modes made for Node, we’re just doing what Node requires (assuming it’s invoked with no special CLI flags altering the behavior) as far as I know. If we were to emit a image text
|
@andrewbranch right - i'm asking for there to be a way to emit |
There is, just name your files |
ah, ok great thanks :-) |
See the following {
"compilerOptions": {
"moduleResolution": "bundler",
"allowImportingTsExtensions": true
}
} |
Search Terms
.ts
suffix
imports
extension
Suggestion
Typescript doesn't recognize file imports with
.ts
suffix.Allow voluntary
.ts
to be added to import paths.Use Cases
It seems right to be able to use a correct path to a file without magic resolution.
This would help to align with deno which uses mandatory suffixes o files.
Examples
let
import a from "path/to/a.ts"
behave the same as
import a from "path/to/a"
Checklist
My suggestion meets these guidelines:
The text was updated successfully, but these errors were encountered: