Repository: TypeScript
Issue: Wildcard/star export from type expression
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

- `"export ="`
- `"export type ="`
- `flatten type export`
- `export top-level type`
- `wildcard export type`
- `star export type`
- `"export *"`
- `"export type *"`

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Introduce syntax for exporting a "spread" type:

```ts
// 1. This is based on ES export lists and spread tuple types. It would only be
//    valid for types, since modules have to be statically analyzable:
export { ...ComplexType };
export type { ...ComplexType };

// 2. Not currently valid in normal type expressions, so might be
//    unexpected, even if it mirrors valid ES syntax. However, it might be
//    something to consider allowing independently, since it's not quite the
//    same as an intersection type, and would be useful for "overwriting"
//    properties:
type Spread = { ...ComplexType };
//              ^ Member 'Complex' implicitly has an 'any' type. (7008)

// 3. These are probably too "generic" and easy to confuse with other export
//    syntax, and doesn't make the required "object" shape obvious:
export ComplexType;          // spread
export type ComplexType;     // spread
export type Other = boolean; // NOT spread

// 4. Barrel export syntax would be a bit more explicit, and mirrors their
//    respective import syntax nicely:
import type * as ComplexType from "./a.ts";
export type * from ComplexType;       // inverse of the import
export type { Foo } from ComplexType; // also potentially nice to have

// 5. An alternative based on CommonJS top-level export syntax, but probably
//    undesirable to use for ES modules:
export = { Foo: "a", Bar: 1 }; // top-level value
export type = ComplexType;     // top-level ("spread") type
```

I'd personally prefer (4), but if extending spreading to object types is feasible, (1) would also be a natural choice.

### 📃 Motivating Example

Not having "spreadable" type exports requires a lot of repetition in cases like this one, which this feature would alleviate significantly:

```tsx
export type ComplexType = {
   Foo: string,
   Bar: number,
};

// A. This is how it works right now. Every type name has to be repeated three
//    times each:
export type Foo = ComplexType["Foo"];
export type Bar = ComplexType["Bar"];
export { Foo, Bar };

// B. This is what you could do instead:
export type * from ComplexType; // (4)
export type { ...ComplexType }; // (1)

// C. You could even trivially allow mapped/filtered exports
export type * from {  [K in keyof ComplexType]: K extends 'Bar' ? never : ComplexType[K]; }; // (4)
export type { [K in keyof ComplexType]: K extends 'Bar' ? never : ComplexType[K]; };         // (1)
```

### 💻 Use Cases

See [Motivating Example](#motivating-example)