Name overload term/type module re-export as namespace

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.

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

Martin Johns (@MartinJohns)

Thanks Martin Johns (@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.

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.

Jason Kuhrt (@jasonkuhrt)

Jason Kuhrt (@jasonkuhrt) check out this related issue/discussion:

#39865

Another relevant discussion...

#48764 (comment)

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

Giulio Canti (@gcanti)

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

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

gcanti/fp-ts#1415

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...

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)

So this actually works...

Jason Kuhrt (@jasonkuhrt)

Written by an AI agent (Claude) on behalf of Jason Kuhrt (@jasonkuhrt).

An update: the example in this issue compiles now. Since #50853 (TypeScript 4.9; see #36792), a type alias merges with a namespace re-export of the same name:

// works.ts — compiles
export type Commit = import('./Commit.js').Commit
export * as Commit from './Commit.js'

What still fails is the type-only re-export spelling of the same thing:

// Commit.ts
export type Commit = { readonly sha: string }
export const make = (sha: string): Commit => ({ sha })

// door.ts
export * as Commit from './Commit.js'    // TS2300: Duplicate identifier 'Commit'.
export type { Commit } from './Commit.js' // TS2300: Duplicate identifier 'Commit'.

// use.ts
import * as Door from './door.js'
export const commit: Door.Commit = Door.Commit.make('x')
// TS2749: 'Door.Commit' refers to a value, but is being used as a type here.

Checked with TypeScript 7.1.0-beta and 7.0.0-dev.20260707.2 (module/moduleResolution NodeNext, strict).

Both lines in door.ts declare an alias named Commit, and an alias excludes every other alias of the same name (SymbolFlagsAliasExcludes = SymbolFlagsAlias, typescript-go internal/ast/symbolflags.go). So the import() type alias is the only spelling that works today, and a codebase that bans inline import() types (for example @typescript-eslint/consistent-type-imports with disallowTypeAnnotations: true) has to exempt every file that uses this pattern.

Navigation Menu

Repository navigation

Name overload term/type module re-export as namespace #51109

Suggestion

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Name overload term/type module re-export as namespace #51109

Description

Suggestion

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Activity

MartinJohns commented on Oct 8, 2022

jasonkuhrt commented on Oct 8, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 25, 2022

cruhl commented on Oct 27, 2022

jasonkuhrt commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions