Typescript: Missing declaration in output when importing .d.ts module and using --outdir

Created on 30 Jul 2019  ·  9Comments  ·  Source: microsoft/TypeScript


TypeScript Version: 3.6.0-dev.20190730 (and 3.5.1)


Search Terms: missing declaration module outdir

Code

tsconfig.json:

{
    "compilerOptions": {
        "outDir": "../out",
        "declaration": true
    }
}

main.ts:

import * as SomeDeclarationModule from "./SomeDeclarationModule";

export function fun() : typeof SomeDeclarationModule {
    return { someDeclarationModuleExport: "hi" }
}

SomeDeclarationModule.d.ts

export const someDeclarationModuleExport: string;

Expected behavior:
SomeDeclarationModule.d.ts gets copied into the "outdir".

Actual behavior:
No SomeDeclarationModule.d.ts => an invalid main.d.ts because the module is missing.

The generated main.d.ts:

import * as SomeDeclarationModule from "./SomeDeclarationModule"; // <- !!! missing !!!
export declare function fun(): typeof SomeDeclarationModule;

Playground Link: Sry no repro in playground, but here: typescript-missing-declaration-module-issue.zip (run npx tsc -p src).

Working as Intended

Most helpful comment

Hmm ... all these points (path mapping, file list, circular refs) also apply to imported .ts files. I don't get the difference between relative-imported .ts files (whose declarations are part of the output dir) and relative-imported .d.ts files which are not (which again, produces "intrinsic" invalid declarations).

But, I see that we're going around in circles and my workaround for this situation is kind of okay. As this, let's says "missing feature" is in TypeScript since the beginning (I guess) and I'm the first one requesting it let's ignore it for the moment and wait if more people will report ...

All 9 comments

This is the intended behavior. If we copied declaration files to the output folder, they'd accumulate over the entire dependency chain and you'd end up with graph depth - 1 copies of the same .d.ts file, which ends up causing worse problems.

The expectation is that a dependent project of yours also gets SomeDeclarationModule.d.ts in scope through similar means.

But also for "in project" definitions?

Note the relative import * as SomeDeclarationModule from "./SomeDeclarationModule" which points to a non-existing file _within_ the out dir.

In other words: In this case the imported declaration file is "in scope" _of the compiled program (or project)_ and should therefore be part of its output.

There's no notion of "in project" vs "out of project". .d.ts files are simply never copied to the output folder and never have been.

Yes, this is exactly what I see as a bug here.

TypeScript generates for all reachable relative-imported .ts files a corresponding .d.ts file in the outdir. Why not for for every relative-imported .d.ts?

What's relative and what's not? Are .d.ts files specified through a path mapping to a relative path included, or not? What about .d.ts files that were in the file list, but also were relatively imported from another .d.ts file? What about two .d.ts files that circularly relatively import each other, but aren't imported from any other part of the program?

The current model is extremely simple to explain and predict, which tends to be a highest-order bit when it comes to build system behavior.

Hmm ... all these points (path mapping, file list, circular refs) also apply to imported .ts files. I don't get the difference between relative-imported .ts files (whose declarations are part of the output dir) and relative-imported .d.ts files which are not (which again, produces "intrinsic" invalid declarations).

But, I see that we're going around in circles and my workaround for this situation is kind of okay. As this, let's says "missing feature" is in TypeScript since the beginning (I guess) and I'm the first one requesting it let's ignore it for the moment and wait if more people will report ...

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@ulrichb hi, same issue here. What is your workaround?

I simply don't use a .d.ts and do my declare const ... in a .ts module.

Was this page helpful?
0 / 5 - 0 ratings