Interface that shares name with namespace being dropped

I’m loving this module so thanks @wessberg. I’m using it to take a slice out of the vscode repo and repackage as its own module.

index.ts:

export interface Something {
  type: string;
}

export namespace Something {
  export function forUseCase(): Something {
    // Something useful
  }
}

The resulting bundle’s .d.ts does not include the Something interface, only the namespace.

My use-case is in ggoodman/ts-primitives which pulls vscode source in a build script and produces a slice of the overall repo using rollup in-memory.

The issue is that for consuming libraries, the interface CancellationToken is being stripped from here https://github.com/microsoft/vscode/blob/f8014d495791145f1fac93cc0283737878272129/src/vs/base/common/cancellation.ts#L9-L25

Note that just below is export namespace CancellationToken. You can see what is being produced on unpkg.

[wessberg]

This has been fixed in v1.2.17. I’ve tested a build based on cloning your ts-primitives library, and the CancellationToken is indeed preserved in the output.

[wessberg]

Hey there. Thanks for submitting this issue! I’m glad you like the library.

What you are actually touching on here is a fundamental aspect of rollup-plugin-ts which is that it will deconflict identically named bindings inside the same scope, because it is based on the fundamental assumption that the identifiers may originate from multiple SourceFiles that are brought together and may be identically named.

However, TypeScript also supports declaration merging, and this library attempts to figure out when declaration merging or function overloading is happening (in which case it must not deconflict) or not.

In this particular case, I think what’s happening is that rollup-plugin-ts mistakenly attempts to deconflict the interface from the NameSpace which leads to something like this:

interface Something {
    type: string;
}
declare namespace Something$0 {
    function forUseCase(): Something$0;
}
export { Something };

And this is not actually correct. So to fix this, I’ll need to revisit declaration merging vs deconflicting.