Using a class based react component imported from a `jsx` files produce errors

[joshcartme]

repro: https://github.com/joshcartme/tsgo-jsx-prop-bug

Under tsgo, using a class based react component imported from a jsx files produce errors complaining that the props are not assignable to the component's type.

In the output below MyComponent is a class based component imported from ./component.jsx

tsgo:

$ yarn run tsgo

index.tsx:6:25 - error TS2769: No overload matches this call.
  The last overload gave the following error.
    Type '{ text: string; }' is not assignable to type 'IntrinsicAttributes & IntrinsicClassAttributes<MyComponent> & Readonly<{}>'.
      Property 'text' does not exist on type 'IntrinsicAttributes & IntrinsicClassAttributes<MyComponent> & Readonly<{}>'.

6     return <MyComponent text="hello" />
                          ~~~~

  node_modules/@types/react/index.d.ts:1021:9 - The last overload is declared here.
    1021         constructor(props: P, context: any);
                 ~~~~~~~~~~~

Found 1 error in index.tsx:6

error Command failed with exit code 2.

tsc:

$ yarn run tsc
Done in 1.93s.

[joshcartme]

As of right now, something that is in main but not in a release on npm, this does not happen if you add propTypes to the component in the jsx file. e.g. if it looked like:

import { Component } from "react";
import PropTypes from 'prop-types';

const propTypes = {
    text: PropTypes.string
}

class MyComponent extends Component {
    render() {
        return <p>{this.props.text}</p>;
    }
}

MyComponent.propTypes = propTypes;

export default MyComponent;

[DanielRosenwasser]

This doesn't repro on the declaration files for React 19. They have explicitly removed special handling of propTypes but HAVE ALSO explicitly declared a static propTypes as any. If you try "debugging" what's going on with the newer declaration files, you're going to also be very confused. 🫠

[DanielRosenwasser]

Okay I knew this was due in part to how our JavaScript support tries to be cute about missing type arguments - I never realized how roundabout it was.

So what happens when you write something like

class MyComponent extends Component {
    render() {
        return <p>{this.props.text}</p>;
    }
}

is that we need to fill in the missing type arguments to Component. In a TypeScript file, we'd see the defaults and fill them in as-written.

In a JavaScript file, we do that UNLESS the defaults are {} or unknown, in which case we somehow know better than the person who wrote the default type arguments, and assume you want looser type parameters.

if (isJavaScriptImplicitAny && defaultType && (isTypeIdenticalTo(defaultType, unknownType) || isTypeIdenticalTo(defaultType, emptyObjectType))) {
    defaultType = anyType;
}

As a result, the first type parameter P = {} is instead instantiated with any. Surely that makes sense because it is probably less annoying than requiring most users write something like:

/** @extends {Component<{ text: string }>} */

at the top of their JSX components.

But this behavior is pretty surprising given that quick info shows the type argument defaults as written, instead of what a user will actually get!

In any case, this is why existing code that's "fine" has no error (though note that it has also meant that "bad" code gets no error either). Every component is basically untyped.

---

Okay, so what exactly is happening differently in tsgo/Corsa/TS7.0? Why are you getting errors on "fine" code?

Corsa doesn't yet do the (sketchy) implicit any behavior for type arguments in JavaScript at all. It strictly fills in defaults ({} in this case), and then unknown for any missing type arguments without defaults.

TypeScript doesn't assume that attributes are "open" - the type of your props are closed and you can't provide any undeclared properties as element attributes. So if your props are {}, basically everything except for an empty tag is going to fail! That's why you're getting

Type '{ text: string; }' is not assignable to type 'IntrinsicAttributes & IntrinsicClassAttributes<MyComponent> & Readonly<{}>'

That Readonly<{}> is the thing to really pay attention to - it comes from the new default argument for P in `React.Component<P = {}, S = {}, SS = any>.

---

Okay, so...why does propTypes actually get things back to normal? This is subtle, and it comes from JSX.LibraryManagedAttributes in @types/react@18.

When you introduce a propTypes, some logic kicks in from ReactManagedAttributes to help buy you some type safety:

type ReactManagedAttributes<C, P> = C extends { propTypes: infer T; defaultProps: infer D }
    ? Defaultize<MergePropTypes<P, PropTypes.InferProps<T>>, D>
    : C extends { propTypes: infer T } ? MergePropTypes<P, PropTypes.InferProps<T>>
//    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    : C extends { defaultProps: infer D } ? Defaultize<P, D>
    : P;

The short story is that there is some logic to "merge in" properties inferred from propTypes when you use a component in a tag. So the expected type will be something like

'... & Readonly<{}> & Pick<InferProps<{ text: Validator<string>; }>, "text">'

---

Personally, I think the new behavior is something I'd like to bring in under a --strict flag, or possibly bring under a temporary "give me back the loose behavior" flag.

But there are a few workarounds I would suggest:

1. Wait for us to fix this.
2. Add an /** @extends {Component<SomeExplicitTypeForProps>} */ above every class component you have - I wonder how hard it would be to write a tool for this. In theory it could be a good use case for an AI agent or something.
3. Add an /** @extends {Component<any>} */ - maybe you use a type alias to any called PropsTODO or something.

[DanielRosenwasser]

The TL;DR is just that we need to plumb back the original "fill in type argument" behavior, the above is just a long explanation of why this was so confusing.

[joshcartme]

@DanielRosenwasser thanks for the explanation, that makes a lot of sense! I think we've now cleaned these all up on our end to match the stricter behavior and/or ported the affected jsx components to tsx.

Before this I hadn't thought about how we were getting some type-safety on jsx elements, that's cool 👍