Skip to content

Named re-exports do not include type representations #634

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
marcus-sa opened this issue Mar 9, 2025 · 0 comments
Open

Named re-exports do not include type representations #634

marcus-sa opened this issue Mar 9, 2025 · 0 comments

Comments

@marcus-sa
Copy link
Contributor

marcus-sa commented Mar 9, 2025

When authoring libraries, external APIs are typically exposed through named re-exports in entry points for explicit control.
However, Deepkit doesn't properly modify these named re-exports to include the generated type representations, causing errors when users import types from the library.

Example

Given the following source files:

context.ts

export interface Context {
  // ...
}

index.ts

export { Context } from './context.js';

The current compiled output is:

context.d.ts

export declare type __ΩContext = any[];

context.js

const __ΩContext = [/* ... */];
export { __ΩContext as __ΩContext };

index.d.ts

export { Context } from './context.js';

index.js

export { Context } from './context.js';

Expected Behavior

The index.js and index.d.ts file should automatically include the generated type representation in their exports:

export { Context, __ΩContext } from './context.js';
marcus-sa added a commit to marcus-sa/deepkit-restate that referenced this issue Mar 9, 2025
deepkit doesn't support named re-exports
deepkit/deepkit-framework#634

Signed-off-by: marcus-sa <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant