Name overload term/type module re-export as namespace

[jasonkuhrt]

Suggestion

🔍 Search Terms

I wasn't sure what terms to be searching for this.

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Currently this is possible:

export type A = 1
export namespace A {
  export const foo = 2
}

import { A } from './a.js'

console.log(A.foo)
const A: A = 2 // type errror

However this is not possible:

export type A = 1
export * as A from './something/else/somewhere/else.js'

📃 Motivating Example

I want to be able to reuse a name for a type and namespace for more streamlined downstream usage.

💻 Use Cases

All the same use-cases there already are today for namespace name overloading between terms/types.

[MartinJohns]

I believe this to be a duplicate of #48764 (comment).

[jasonkuhrt]

Thanks @MartinJohns. That issue was about the type import while mine is a suggestion that it should work like namespaces.

That issue was/is closed with the counter-example of importing a class.

What I'm saying here wouldn't be closed because of that counter example.

I'm merely saying it works with namespace and ought to work with native ESM modules now that we have them.

[cruhl]

I have been trying to get something like this working for literal years now.

It would dramatically help write better functional/Rust-module-style code.

[cruhl]

@jasonkuhrt check out this related issue/discussion:

#39865

[cruhl]

Another relevant discussion...

#48764 (comment)

[cruhl]

Good overview of the resulting friction this would alleviate here:
#48764 (comment)

[cruhl]

Here's a good example of the awkwardness this causes for users of @gcanti's fp-ts...
gcanti/fp-ts#1633

[cruhl]

Here is my dream syntax...
import * as User, type { User } from "./User";

[cruhl]

gcanti/fp-ts#1415

[cruhl]

This problem won't be going away anytime soon, so I would expect it to continually pop up so long as issues keep getting closed...

[cruhl]

Oddly, this halfway works, but fails to see export * as Point from "./Point"; correctly...

'Point' only refers to a type, but is being used as a value here.ts(2693)

[cruhl]

So this actually works...

[cruhl]

So this actually works...