export default type

Search Terms

export default type

Suggestion

Allow export default for type.

Use Cases

It would be very nice to have export default type to match with other default exports such as classes and interfaces.

Right now it looks very inconsistent to be able to export anything as default and only types with named export:

export default class MyClass {}
export default interface MyInterface {}
export type MyType = {}

The only way to achieve this now is to use annoying workaround:

type X = number | string

export { X as default }

This may cause confusion for newbies as there are no clear reasons why classes and interfaces can be exported as default, but not the types.

Examples

// x.ts
export default type X = {}

// main.ts
import X from './x'

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, etc.)
This feature would agree with the rest of TypeScript's Design Goals.

(not sure on the last)

I often want to export values which double as types. For instance.

export const Tag = Symbol.for("@my-app/entry.Tag");
export type Tag = typeof Tag;

It feels to me like this should be possible with default exports as well.

Any updates on this?

TypeScript 5.0 (in #52203) introduced a new option called --verbatimModuleSyntax that makes the following code produce the following error: An 'export default' must reference a value when 'verbatimModuleSyntax' is enabled, but 'X' only refers to a type., because the default export X is not clearly marked as a type:

type X = number | string;
export default X;

And a workaround is to mark X as a type in the export declaration by using a named export:

type X = number | string;
export type {X as default}; // or export {type X as default};

But that looks fairly indirect. Having export default type X; would also help making that more straightforward.

was:

type SomePayload = {
 data1: number;
 data2: string;
};
export default SomePayload;

import type SomePayload from './SomePayload.type'

now:

export type SomePayload = {
 data1: number;
 data2: string;
};

import type { SomePayload } from './SomePayload.type'

seems like a bug, because I have 1 type in 1 file

switch Card form interface to type

For those who were looking for "Type annotations for export default", follow #13626.

And a workaround is to mark X as a type in the export declaration by using a named export:

type X = number | string;
export type {X as default}; // or export {type X as default};

But that looks fairly indirect. Having export default type X; would also help making that more straightforward.

In addition, while the following is possible :

export type Fraction = IFraction;
export const Fraction = Implementation;

The following gives an error :

export type { IFraction as default };
export default Implementation;

because it doesn't allow multiple default exports.
As pointed out earlier, it means that my clients will need to write import { Fraction } from "fractions"; rather than import Fraction from "fractions";, and that the default export is not treated the same as the other exports.

Would very much like to see this. I'm using verbatimModuleSyntax, and while I can default export interfaces just fine, I can't do that for type aliases. It's causing me to use an unpleasant mix of // @ts-* comments and breaking my own conventions.

Navigation Menu

Repository navigation

export default type #41409

Search Terms

Suggestion

Use Cases

Examples

Checklist

was:

now:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

export default type #41409

Description

Search Terms

Suggestion

Use Cases

Examples

Checklist

Activity

harrysolovay commented on Dec 3, 2020

hopeless-programmer-online commented on Apr 16, 2021

PolariTOON commented on Mar 28, 2023

AndreiSoroka commented on Sep 9, 2023

was:

now:

movahhedi commented on May 14, 2024

Gouvernathor commented on Jul 19, 2025

Squidgical commented on Nov 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions