[api-extractor] import() types are not handled correctly in .d.ts rollups

[alan-agius4]

Lazy types are not being rewired when using dtsRollup.

index.d.ts

export declare const ɵdefineDirective: import("./nested").CssSelector[];

nested.d.ts

export const enum SelectorFlags {
	NOT = 0b0001
}

export type CssSelector = (string | SelectorFlags)[];

output

export declare const ɵdefineDirective: import("./test-nested").CssSelector[];

export { }

I'd expect that the lazy type is resolved and appended to the file and the import is removed.

expected output

export const enum SelectorFlags {
	NOT = 0b0001
}

export type CssSelector = (string | SelectorFlags)[];
export declare const ɵdefineDirective: CssSelector[];

export { }

version: 7.0.11

[octogonz]

export declare const ɵdefineDirective: import("./nested").CssSelector[];

Oh man... do people really do this? :-P Is there a practical reason why this shouldn't be replaced by a conventional named import?

API Extractor should add support for this in theory, but I've been trying to triage people's feature requests into 3 categories:

1. Language features that are "recommended" according to our team's API design philosophy [100% supported]
2. All other commonly used language features, in their simplest syntax [AE7 represents major progress in this area]
3. Alternate syntaxes that can be replaced by an equivalent form from #2 [lowest priority, although people are encouraged to contribute PRs]

Inline import statements seem like they would definitely be in category #3.

[alan-agius4]

@pgonzal, the lazy import is not written in code, but emitted by the ts compiler.

Example having the following
nested.ts

export enum SelectorFlags {
	NOT = 0b0001
}

export type CssSelector = (string | SelectorFlags)[];

export function foo(): CssSelector {
	return;
}

index.ts

import { foo } from "./nested";

export const x = foo();

index.d.ts

export declare const x: (string | import("./nested").SelectorFlags)[];

While this can be trivial to fix and not rely on type inference, I'd at least expect that the dts bundler to emit some sort of error to warn the user.

[octogonz]

Ahh thanks for clarifying. This should be pretty easy to fix I think.

[octogonz]

BTW the "easy" fix is to report an error when this is encountered. Properly rewiring the import statements is not easy, since in general the referenced module may not be exported at all.

[Swatinem]

Hi! Author of rollup-plugin-dts here :-)

I just did a short comparison of some edge-cases between api-extractor and my plugin and noticed that your specific usecase might be supported by my plugin without a problem.
Feel free to try it and give some feedback :-)

[phryneas]

I believe we're also encountering that bug when trying to build https://github.com/async-library/react-async with pika, which internally uses api-extractor.

Typescript creates type files with import type references like state: AsyncState<T, import("./Async").AbstractState<T>>; and api-extractor then fails to inline those, resulting in a final file like this: https://gist.github.com/phryneas/d101e7e0b8070f6dc8b44540825c87cd#file-index-d-ts-L220 (line 220)

Could you take another look at this please?
(Original issue over at pika FredKSchott/pika-pack-builders#87 )

[octogonz]

@phryneas Can you share a repro branch that I could use to investigate/debug this?