Exported type merged with 'export * as namespace...' only exports type meaning.

[rbuckton]

Previously I liked using TS namespaces and declaration merging for creating FP-style modules, without needing the MyModule.T convention:

export type Foobar = { }

export namespace Foobar {
  export function doStuff(foobar: Foobar) { }
}

import { Foobar } from './Foobar'

Foobar.doStuff(fb)

Namespaces are not really the way to go any more, babel doesn't support them, they probably aren't tree-shakeable etc. But I was hoping that the export * as ns syntax could be > used as a replacement, like this:

export type Foobar = import('./Foobar').Foobar

// Or:
// export type { Foobar } from './Foobar'

export * as Foobar from './Foobar'

This seems to pass the nightly compiler, but the compiler only knows that Foobar is re-exported as a type, not a value. It would be great if the compiler could merge them into a combined value & type like with namespaces.

Originally posted by @katis in #4813 (comment)

[jasonkuhrt]

We have certain projects/modules making heavy use of this pattern. The writing is on the wall though that we're in need of change:

• no tree shaking support
• eslint warnings by default
• no support for re-exports/barrel-exports like modules (aka. TS namespaces since being introduced have not kept apace with module namespaces)

I guess I don't have much to add to this issue, its well described, and our use-case is similar. I just wish I could +1000 it :)

[nexsodev]

Same here, my case:

export * from './types/index.js';

export {
  RequestContext,
  ResponsePayload,
};

In a:

import { RequestContext,  } from '@ns/package';

Only the options: RequestContext and ResponsePayload are showed, none of the types is present, but it works in runtime.

types/index.js is:

// ...
export * from './client-error/index.js';
export * from './server-error/index.js';

export {
  GenericHttpError,
};