[Bug]: `react/prop-types` false positive when using `React.ComponentProps`

[Mathias-S]

Is there an existing issue for this?

• I have searched the existing issues and my issue is unique
• My issue appears in the command-line and not only in the text editor

Description Overview

When using certain React types in TypeScript, such as React.ComponentProps, the react/prop-types rule will trigger a false positive when using a property from that type.

import React from "react";

// ERROR
export function LinkWithComponentProps(props: React.ComponentProps<"a">) {
    return <a href={props.href}>My link</a>;
    //                    ^ 'href' is missing in props validation  eslint(react/prop-types)
}

// ERROR
type TypeProps = React.ComponentProps<"a">;
export function LinkWithTypeProps(props: TypeProps) {
    return <a href={props.href}>My link</a>;
    //                    ^ 'href' is missing in props validation  eslint(react/prop-types)
}

// NO ERROR
interface InterfaceProps extends React.ComponentProps<"a"> {}
export function LinkWithInterfaceProps(props: InterfaceProps) {
    return <a href={props.href}>My link</a>;
}

Linting the above code using eslint . --ext .tsx gives the following error:

/path/to/eslint-test/test.tsx
   5:27  error  'href' is missing in props validation  react/prop-types
  12:27  error  'href' is missing in props validation  react/prop-types

Using the following versions:

    "@types/react": "^18.2.37",
    "@typescript-eslint/parser": "^6.10.0",
    "eslint": "^8.53.0",
    "eslint-plugin-react": "^7.33.2",
    "typescript": "^5.2.2"

And the following configuration:

module.exports = {
  env: { browser: true, node: true },
  extends: ["plugin:react/recommended"],
  parser: "@typescript-eslint/parser",
  settings: {
    react: { version: "detect" },
  },
  plugins: ["react"],
};

Expected Behavior

Using React.ComponentProps<"a"> or similar types such as ComponentPropsWithRef and ComponentPropsWithoutRef directly as types should not result in an error, and should work the same way as defining an interface that extends these types.

A minimal reproduction repository can be shared if needed.

eslint-plugin-react version

v.7.33.2

eslint version

v8.53.0

node version

v20.9.0

[ljharb]

I'd never heard of either of those built-in types, so we'd have to build support for them before they can be understood statically.

[branko-d]

Another example of a false positive:

const LavanderDiv: React.FC<React.ComponentProps<"div">> = ({ style }) => {
    return <div
        style={
            {
                backgroundColor: "lavenderblush",
                ...style
            }
        }
    />;
}

error 'style' is missing in props validation react/prop-types

Despite that, hovering over style shows its type: React.CSSProperties | undefined, and everything builds as expected.

If it matters, here is an excerpt from my package.json:

    "devDependencies": {
        "@types/eslint": "^8",
        "@types/node": "^20.10.0",
        "@types/react": "^18.2.39",
        "@types/react-dom": "^18.2.17",
        "@typescript-eslint/eslint-plugin": "^6.13.1",
        "@typescript-eslint/parser": "^6.13.1",
        "eslint": "^8.54.0",
        "eslint-plugin-react": "^7.33.2",
        "typescript": "^4.9.5",
        ...
    },
    "dependencies": {
        "react": "^18.2.0",
        "react-dom": "^18.2.0",
        ...
    },

[ljharb]

The hover is the typescript language server; again, we’d need to hardcode support for those types (or, the TS eslint parser would need to attach the type information to the AST nodes) to be able to support them.

[burtek]

Honestly, I don't think there is a point in using eslint for type-checking TS prop types as TS already does this. That being said

TS eslint parser would need to attach the type information to the AST nodes

pretty sure you can extract that info from AST one way or another if eslint config has type linting enabled

[corydeppen]

I think this may have been mostly resolved by #3859, but it looks like ComponentPropsWithRef is still subject to this issue and may need to be added to the list of allowed generic types.

@ljharb I'd be happy to submit a PR if you can confirm it's appropriate.

[ljharb]

@corydeppen with tests, that sounds great :-)