(react props) is missing in props validation ERROR

[S-Amin]

I just tested the version 7.20.6 and I got the error ... is missing in props validation .
It's a Nextjs project and I want to add the linting now but I got the error on my components
this is my package dependency

        "eslint": "^7.7.0",
        "eslint-config-airbnb-typescript": "^9.0.0",
        "eslint-config-prettier": "^6.11.0",
        "eslint-plugin-import": "^2.22.0",
        "eslint-plugin-jsx-a11y": "^6.3.1",
        "eslint-plugin-prettier": "^3.1.4",
        "eslint-plugin-react": "^7.20.6",
        "eslint-plugin-react-hooks": "^4.0.8",

this is the eslint consfig file

{
    "env": {
        "browser": true,
        "es2020": true
    },
    "extends": [
        "airbnb-typescript",
        // "eslint:recommended",
        // "plugin:react/recommended",
        "plugin:@typescript-eslint/recommended",
        "prettier",
        "prettier/react",
        "prettier/@typescript-eslint",
        "plugin:prettier/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "project": "./tsconfig.json",
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": ["react", "@typescript-eslint"],
    "rules": {
        "prettier/prettier": ["error"],
        "react/react-in-jsx-scope": "off",
        "import/prefer-default-export": "warn",
        "no-underscore-dangle": "off",
        "no-nested-ternary": "off",
        "@typescript-eslint/no-empty-interface": "warn",
        "@typescript-eslint/naming-convention": [
            "error",
            {
                "selector": "interface",
                "format": ["camelCase", "UPPER_CASE", "PascalCase"]
            }
        ]
    }
}

and there are multiple components that eslint threw this error ... is missing in props validation

[ljharb]

Please provide exact component code that's being warned on, and the exact text of the warnings.

What's likely happening is that a bunch of missing propTypes are being properly detected now that component detection has been improved to catch a new class of cases.

[S-Amin]

One of the components is this:

interface Props {
    posts: string[];
}
const Home: NextPage<Props> = ({ posts }) => {
    function onChange(date, dateString) {
        console.log(date, dateString);
    }

    function check() {}

    return (
        <div style={{ marginTop: 100 }}>
            <Form layout="horizontal">
                <DatePicker onChange={onChange} picker="week" />
                <Button onClick={check}>check Token</Button>
                <FormItem
                    style={{ marginTop: 48 }}
                    wrapperCol={{ span: 8, offset: 8 }}
                >
                    <Button size="large" type="primary">
                        +
                    </Button>
                    <Button size="large">-</Button>
                </FormItem>
            </Form>
            <Card
                title="Default size card"
                extra={<a href="/">More</a>}
                className={sass.test}
            >
                {posts.map((item, i) => (
                    <p key={i}>{item}</p>
                ))}
                <p>Card content</p>
                <p>Card content</p>
            </Card>
        </div>
    );
};

export async function getServerSideProps(ctx: NextPageContext) {
    return { props: { posts: ["test", "test2"] } };
}

export default Home;

and the error is :

 14:34  error    'posts' is missing in props validation       react/prop-types
 43:24  error    'posts.map' is missing in props validation   react/prop-types

[ljharb]

what's NextPage? React components usually aren't typed like that.

[S-Amin]

this is a page in nextjs and the same error appear in my components too.
the problem is that eslint can't understand the prop interface when I'm using arrow function.

[ljharb]

Ah. That's a limitation in the TS parser; the type is associated with the variable and not with the arrow function

Components shouldn't be arrow functions anyways - make them proper named functions, and the types will work properly too.

[S-Amin]

I can't see why I shouldn't use arrow functions. just because a bug in TS or a package?

[ljharb]

In general, because arrow functions don't have explicit names, it makes them worse for debuggability. That the TS eslint parser can't properly associate type information to them is just another reason on top of the regular JS one.

[S-Amin]

So is there any plan to fix this bug or not?

[ljharb]

I'd like it fixed, despite the arrow function advice, but I believe the issue is in the typescript eslint parser. @bradzacher, can you confirm?

iow, if there's something we can do here to associate the right type information with arrow function components, I'm happy to make the change here, but I think to be practical the parser would have to attach it to the arrow function AST node.

[bradzacher]

In general, because arrow functions don't have explicit names, it makes them worse for debuggability

JS Engines (at least chrome..) actually do implicit naming for arrow functions based on the name of the variable:

So I don't think there's a difference between function decls and arrow functions in this regard.

---

but I believe the issue is in the typescript eslint parser

In this case, no - the AST is working as expected: the type annotation is on the variable declaration, not the function argument.
You will get roughly the same AST shape with babel parsing TS, or any flow parser as well.

This plugin would have to traverse the parent in order to find the annotation, and then do some handling of the type to find the prop type.

Common cases it could handle:

• React.SFC
• React.StatelessComponent
• React.FunctionComponent
• React.FC

The "handling" would essentially be:

1. annotation = id.typeAnnotation.typeAnnotation
2. if (annotation.type !== 'TSTypeReference' && annotation.typeParameters == null) return; (not a generic type with type params)
3. if (!allowedTypes.has(context.getSourceCode().getText(annotation.typeName).replace(/ /g, ''))) return (note an allowed generic type)
4. follow the reference from the generic parameter to the props def.
5. validate prop type against prop def

[ljharb]

@bradzacher yes, the spec has inferred names, but they don't always apply intuitively (so it's easy for devs to think they're inferred when they're not) and when debugging in browsers that lack name inference, the name might not show up at all.

---

In that case it seems like a flaw in TS itself :-/ it seems like we need a helper in our component detection that can get the type (when it doesn't exist on the component, only on the variable that holds it). PRs welcome.

[bradzacher]

In that case it seems like a flaw in TS itself

For function expressions (arrow or otherwise) assigned to a variable declaration, parameter declaration, returned from a function or assigned to a property, both flow and TS will infer function parameter types for you based on the contextual type (i.e. the annotated type of the variable, parameter, function signature return, or object property, respectively).

This inference greatly simplifies DevX without sacrificing any readability or usability. It does however mean analysis tools have to take on more burden to analyse the code.

Note that the @typescript-eslint tooling will include some limited type information here. But depending on the user's setup it might be unreliable.

We provide two flavours:

• single-file (isolated) types (provided by default, for free)
  • This will give you types for simple cases. However in cases where you provide types based on external types (i.e. React.FunctionalComponent<Props>), it won't really help because, well, it's isolated to analysing a single file only.
• complete project types (requires configuration by the user)
  • This will always give you types for all cases. However it comes with a lint-time cost (as TS has to analyse the entire project). For that reason, a number of users don't enable this functionality.

I figured this plugin wouldn't want to add a type-aware lint rule (as it restricts the rule's usability a bit), so to make this work you'd have to do this entirely based on the AST analysis.

[ljharb]

I guess I'd expect inferred types to show up directly on the nodes they're inferred on :-/

I agree that we wouldn't want the "complete project types" option by default. However, I think we'd always want to incur same-file cost for figuring out the type of a component, specifically (as opposed to everything else).