Preserve export context of export statements

[superguineapig]

Hi there! First, this is a very useful plugin so thanks!

Ok, so I've got a project that rolls-up the .d.ts files using this plugin. All good. However, I've got a peculiar situation where I'm performing additional post-processing on the output as part of my build toolchain. (part of a phased adoption of TS in a very large codebase).

The post-processing relies upon the use of explicit export ... and export type ... statements. (added way back in TS v3.8) It seems that rollup-plugin-dts outputs the more-common general export { ... } form when collecting things-to-be-exported. That's totally reasonable and probably fits everyone's use-case but mine.

An example of what currently happens:

input_file1.d.ts

export interface AnInterface {
    // ...
}

export declare type ATypeAlias = string | null;

export declare class AClass {
    // ...
}

export declare const ArrayOfString: string[];

export declare function getWidget(n: number): Widget;

The exports of input_file1.d.ts are collected, stripped, and consolidated into a single export like so:

output_file1.d.ts

/* individual exports have been removed */
interface AnInterface {
    // ...
}
declare type ATypeAlias = string | null;
declare class AClass {
    // ...
}
declare const ArrayOfString: string[];
declare function getWidget(n: number): Widget;

/* single aggregated export */
export { AClass, AnInterface,  ArrayOfString, ATypeAlias, getWidget };

What I'd like to happen

Ideally, in my situation, I'd like to have the original (input file's) export context preserved in the output. I.e. Value-ish declarations are exported, and Type-ish declarations are export typeed like so:

(still using 'input_file1.d.ts')

output_file2.d.ts

// ...
// declarations here
// ...

// value-ish types use generic export
export { AClass, ArrayOfString, getWidget };

// type-ish types use explicit type export
export type { AnInterface, ATypeAlias };

This preserves the original exported context.

Implementation

I was taking a look through the code and at first glance, this behavior should be possible through modifications in the pre-processing algorithm

I was thinking maybe store a tuple or simple object in the exportedNames Set instead of just a string to also carry information about the original context:

rollup-plugin-dts/src/transform/preprocess.ts

Lines 39 to 40 in 900367a

	/** All the names that are exported. */
	const exportedNames = new Set<string>();

Perhaps something like this?

// simple
type ExportContext = [string, boolean]; // [ exported name, isTypeIsh ]
const exportedNames = new Set<ExportContext>();

// Or something more detailed for future use:
enum DeclKind {
    Class,
    Enum,
    Function,
    Interface,
    Module,
    Type,
    Variable,
}
type ExportContext = [string, DeclKind]; 
const exportedNames = new Set<ExportContext>();

Then while walking the sourceFile.statements nodes:

// ...

// include the simple 'isTypeIsh' flag
exportedNames.add( [ name, true ] );

// OR

// include the full context of the original export stmt
exportedNames.add( [ name, DeclKind.Interface ] );

// ...

Then later during "Pass 2"

rollup-plugin-dts/src/transform/preprocess.ts

Lines 216 to 218 in 900367a

	if (exportedNames.size) {
	code.append(`\nexport { ${[...exportedNames].join(", ")} };\n`);
	}

It would be possible to filter the exportedNames Set into multiple iterables for each kind of export statement; export { <value-ish> } and export type { <type-ish> }

Opt-in

Assuming it's possible to do this, it should also be possible to put this new output behavior behind a plugin config parameter that defaults to not doing this, to avoid breaking anyone's existing setup/assumptions/expectations of the output.
Something like exportsWithContext: true would do.

Thoughts?

Like I said, my crazy setup requires that there be both export { ... } and export type { ... } present in '.d.ts' files to differentiate between values and types at a later stage of my build process.

This seems like adding this output behavior could be a decent addition to the plugin since the semantics of using export type are fairly well-established by TS.

However, I'm neither super familiar with TS nor the architecture of this plugin to confidently state whether or not implementing this behavior would be possible/challenging/far-reaching/etc. Thoughts are welcome from maintainers/contributors!

And, hey, thanks for reading this.

[Swatinem]

This is an interesting proposition. So far export/import type is not supported due to the fact that rollup itself does not know of these concepts.

Instead of handling this in the pre-processor, this would need to happen in post-processing, after rollup itself has done its magic and you end up with a final export list. In that step, you would have to walk the AST and collect the declaration type of every item as you suggested, and then split the export { ... } declaration into another export type { ... } declaration.

[superguineapig]

Just for clarification, do you mean "post-processing" in the context of this plugin's implementation (at runtime), another plugin running after this plugin, or a process outside of rollup to be run after rollup is done generating all of its output?

I'm completely new to rollup and don't totally grok the lifecycle/ecosystem just yet.

[Swatinem]

In terms of this plugin, that would be in the renderChunk hook:

rollup-plugin-dts/src/transform/index.ts

Line 97 in 900367a

renderChunk(code, chunk, options) {

So the plugin has another pass over the rollup output.

[superguineapig]

Ok. Looks like I need to do a little more research into the architecture before attempting any implementation.

Thanks for pointing me in the right direction.