Change declaration file import paths from .js to .d.ts

[frehner]

Suggestion

🔍 Search Terms

• declaration import paths
• esnext declaration import path

I also know there's a lot of somewhat-related conversation around this area in #37582 and #46452 , but this is only for the output of declaration files, so I'm not sure if it's exactly related to those issues or not. If it is, feel free to close this and accept my apologies.

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

When using TypeScript to emitDeclarationOnly, it outputs a .d.ts file. However, the contents of that file keep the same import path. An example:

// in `index.d.ts`
export {TestFunc} from './other.js';

What would be nice, however, is to have the declaration file import paths point to the actual file, like so:

// in `index.d.ts`
export {TestFunc} from './other.d.ts';

To maybe help see more clearly, I created this repo that has the current source code and output files when running npx tsc --emitDeclarationOnly. You'll note that the /types/index.d.ts file has an import/export path to a file that doesn't actually exist, but is still found when using something like node's resolution algorithm.

📃 Motivating Example

When using Deno, you can put up your library + types up on a CDN. However, Deno must have the exact path to the file in order for it to work. Unfortunately it seems that it means that the other declaration files cannot be found because the import path in the declaration file isn't exactly correct.

Unless I've missed something important about TS / Deno?

💻 Use Cases

I don't think this would have any effects on the ecosystem, would it? Is there a chance it would maybe even make things slightly faster when looking up types (even for node projects), because the declaration files are pointing directly to the correct file instead of having to go through the resolution algorithm? I'm not sure, I'll defer to you experts.

Thank you ❤️

[frehner]

Sorry, I think I should be more clear:

In this case, I have a library that I bundle to JS, and additionally add TS types to the output.

When using Deno's "providing types when importing" guide, I can point to my emitted .d.ts file but things fail from there because that file then tries to import from .js files instead of from .d.ts files (as outlined above), which breaks Deno's resolution.

[andrewbranch]

It’s important to note that import {} from "./foo.d.ts", whether in a .d.ts file or any other kind of file, does not resolve in TypeScript today under any resolution mode. I plan to change that as part of #50152 (in fact already implemented in #50153), but if you read through that proposal, hopefully you’ll see that this is a more complicated request than it sounds like.

[frehner]

It’s important to note that import {} from "./foo.d.ts", whether in a .d.ts file or any other kind of file, does not resolve in TypeScript today under any resolution mode.

Ah good to know, I hadn't even tested it because I assumed it just worked.

I plan to change that as part of #50152 (in fact already implemented in #50153),

Exciting!

but if you read through that proposal, hopefully you’ll see that this is a more complicated request than it sounds like.

Indeed. I appreciate the work you're doing here. Thank you for the response!