[request] allow `export type * from`

[bluelovers]

Search Terms

export type

Suggestion

TS1383: Only named exports may use 'export type'.

allow export type * from

Use Cases

https://github.com/bluelovers/ws-ts-type/blob/master/packages/ts-type/index.ts

export type * from './lib';
export type * from 'typedarray-dts';

Examples

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.

[adjerbetian]

Any news on this topic?

[aminya]

In addition to all the usecases that export type has, not having it is an inconsistency in the TypeScript language that should be fixed.

P.S: the number of upvotes and likes shows the community opinion. I think "Awaiting more feedback" label should be removed. @RyanCavanaugh

[FezVrasta]

Just adding my use case here, I maintain a quite popular library (Popper) and I need a way to expose the TS types like I do in Flow (the system used to type the codebase). In Flow I can do export type * from './something' so I'd like to do the same in TS, or have an alternative.

[somebody1234]

I want to use it to pin dependency versions in Deno... wonder if there's any workaround because I feel like most alternative solutions are very not ergonomic
(edit: it (export *) appears to work... sometimes? i have no clue tbh...)

[parzhitsky]

Stumbled upon this issue just now.

My use case is that there are definition files *.type.ts, which are intended for exporting only types, and a package entry-point file index.ts which gathers and re-exports all public API from other files (there are some limitations with using *.d.ts initially in source code; unfortunately, I don't remember exactly what's wrong with this approach, but the bottom line is that I have to use custom *.type.ts files):

// thing.type.ts
type Primitive = string | number | boolean; // not exported

export type ThingPropConstraint = Primitive | object;

export interface Thing<Prop extends ThingPropConstraint> {
  prop: Prop;
}

// value.ts
export const value = 42;

// index.ts
export * from "./thing.type";
export * from "./value";

Since *.js output of *.type.ts files will (by convention) always be basically empty, I then remove *.js and *.js.map output files for them, leaving only *.d.ts behind.

Eventually, I expect type exports to be removed from index.js (the output file), leaving only value exports, – but type exports are preserved; and, since the files are gone, this results in an error:

// (output excerpt)
__exportStar(require("./thing.type"), exports); // Error: Cannot find module './thing.type'
__exportStar(require("./value"), exports);

I'd like to enforce TypeScript to remove this export construct:

// index.ts
export type * from "./thing.type";
export * from "./value";

---

The point of this example is that definition files can define more than one entity, and the information about the exact entities being exporting from a definition file must be preserved in this file (SRP), so re-exporting them must be done using an "export start" kind of export; otherwise, adding another definition will result in constant going back-and-forth between definition files and entry point file.

[parzhitsky]

@bluelovers Can I ask you to properly fill all the sections in the original comment (search terms, examples, checklist)?

[arthurfiorette]

Any plans to implement this feature?

[ASDFGerte]

I'm re-exporting type-utilities, keeping the related files as .d.ts (export-statements must be erased). Due to this feature missing, i need to write out every exported type: export type { typeA, typeB, /* ... */ } from './path/file';, and when adding a new type, not forget to add it there too. Luckily import type * exists, so the consumer doesn't have the same problem, but it's a (small) inconvenience.

[nicolo-ribaudo]

I just stumbled upon this.

We have a file that only contains type annotations (https://github.com/babel/babel/blob/main/packages/babel-types/src/ast-types/generated/index.ts), and we currently re-export it internally using export * from "..." (https://github.com/babel/babel/blob/d4d08d906a8c5c53cdf5fb0024def91fbfa51698/packages/babel-types/src/index.ts#L101).

When publishing, we strip away TS types and compile to CJS. The types-only files becomes an empty CJS module, and our entry point ends up having some unnecessary code for export * from "...".

Apparently, that empty CJS file causes problems with some tools (babel/babel#14634, https://stackoverflow.com/questions/71045195/cannot-build-run-devserver-cause-of-babel-loader, https://openclassrooms.com/forum/sujet/babel-loader-not-working, kriszyp/lmdb-js#51). It's a bug with those tools, but it would be nice if we could entirely avoid it by marking that re-export as type-only since it's a file that is not needed at runtime.