Declaration emit inlines types incorrectly

[eps1lon]

🔎 Search Terms

declaration emit inline

🕗 Version & Regression Information

I was unable to test this prior to 4.4 since React types are no longer compatible with that version.

⏯ Playground Link

No response

💻 Code

import * as React from "react";

export class Component extends React.Component<{ children: React.ReactNode }> {
  render() {
    if (Math.random()) {
      return <div>{this.props.children}</div>;
    } else {
      return this.props.children;
    }
  }
}

Full repro: https://github.com/eps1lon/ts-module-auto-export/tree/bad-inline

🙁 Actual behavior

Return value from render() is not referencing React.ReactNode but inlines its (incomplete) union members:

import * as React from "react";
export declare class Component extends React.Component<{
    children: React.ReactNode;
}> {
    render(): string | number | boolean | Iterable<React.ReactNode> | import("react/jsx-runtime").JSX.Element;
}

🙂 Expected behavior

Return type references the type alias. Inlining union members is incorrect (we may add or remove members or treat members as internal, local types) generally and here specially not even using all members.

export declare class Component extends React.Component<{
  children: React.ReactNode;
}> {
  render(): React.ReactNode | import("react/jsx-runtime").JSX.Element;
}

Additional information about the issue

The fact that it inlines the type here is a special case of #37151. #37151 is a more general since it's not always clear when inlining is correct or not. I'd be curious to know what would break if TS would not stop inlining in this special case.

But this issue is also broader since the inline is incomplete.

[RyanCavanaugh]

What's incomplete about this? I don't see any missing things in the union

[eps1lon]

-string | number | boolean | Iterable<React.ReactNode>
+string | number | boolean | Iterable<React.ReactNode> | React.ReactElement | null | undefined | React.ReactPortal

React.ReactElement is not the same as React.JSX.Element since they're different interfaces.

But that's not the focus here. The problem is that TypeScript inlines in the first place here. Especially because the same version of the published types can have different versions of ReactNode due to module augmentation.