eslint-plugin-react: no-unused-prop-types + Typescript : error is not reported

Hey there! And thx for this wonderful plugin that help our team everyday 🚀 .

However, we face a problem on configuration of a new Typescript project with eslint + eslint-plugin-react: we can’t make the rule react/no-unused-prop-types output any error (no idea if this is the only rule that is ignored, but this one is pretty helpful).

import React from "react";

type Props = {
  foo: string;
  bar: string; // <-- unused prop
};

const Demo = (props: Props): React.ReactNode => {
  return <div>{props.foo}</div>;
};

export default Demo;

Here we expect eslint to detect that bar is unused and report it. But unfortunately it’s not. I’ve setup a little repo to illustrate the problem: https://github.com/meriadec/the-unused-prop-type

eslint config looks like this:

module.exports = {
  parser: "@typescript-eslint/parser",
  extends: ["plugin:react/recommended"],
  parserOptions: {
    ecmaVersion: 2018,
    sourceType: "module",
    ecmaFeatures: {
      jsx: true
    }
  },
  settings: {
    react: {
      version: "detect"
    }
  },
  rules: {
    "react/no-unused-prop-types": 2
  }
};

Not sure if the problem is related to @typescript-eslint/parser or eslint-plugin-react though. Could not find really relevant other issues raising the problem, so I hope there is something obvious that we are missing and that someone can point us 😄

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 12
Comments: 24 (9 by maintainers)

Commits related to this issue

[Fix] `no-unused-prop-types`: fix with typescript eslint parser Fixes #2569. Co-authored-by: Antoine <antoine.sauvage@melix.net> Co-authored-by: Jordan Harband <ljharb@gmail.com> — committed to ovrsea/eslint-plugin-react by eltonio450 4 years ago
[Fix] `no-unused-prop-types`: fix with typescript eslint parser Fixes #2569. Co-authored-by: Antoine <antoine.sauvage@melix.net> Co-authored-by: Jordan Harband <ljharb@gmail.com> — committed to ovrsea/eslint-plugin-react by eltonio450 4 years ago

Most upvoted comments

in .eslintrc :

"rules": {   
    "react/prop-types": 0
  }

saostad on Mar 8, 2020

It’s not a conflict; you should be using PropTypes and types, since types can’t cover most of what PropTypes can.

ljharb on Mar 9, 2020

ok, so it already works with interface, but not with type, bc I mixed the parsers in my PR 😦 #2661 + added bugs to unhandled edge cases

but @hank121314 made a huge work refactoring, cleaning and fixing bugs related to props declaration in typescript in #2721 (thank you very much!), so it should work in the next release 👍

overall, typescript props declaration to “eslint usable format” seems to be behind us now 😃

eltonio450 on Aug 7, 2020

Hi everyone,

It turns out the typescript parser references the type node as “TSTypeReference”, and from there, the reconciliation with the type declaration was not implemented. I added it to propTypes.js, but i feel that I may have forgotten edge cases. If one of you who knows better the code base than me could have a look and tell me what’s left to do, it would be awesome 😃

Thank you !

eltonio450 on Jun 7, 2020

I investigated this a bit further. In my case. component.declaredPropTypes is always {} so the parser does not find the prop declarations. I’m a bit lost debugging this further. My current thesis is that propTypes#resolveTypeAnnotation fails to correctly resolve to the type definition.

I also noted that the nodes in my case have types like TSTypeReference and TSTypeAnnotation and the plugin code does not seem to know what to do with them.

Any idea on which direction to go from here?

Xiphe on Mar 5, 2020

Just to let y’all know, I wont have time to look deeper into this in the near future. Good Luck 👍

Xiphe on Apr 7, 2020

Integers, to name something incredibly basic. Strings that match regular expressions. https://npmjs.com/airbnb-prop-types has a ton of use cases.

They both absolutely work together! The only challenge is when a propType and a flow/TS type would be redundant - in that case, either just duplicate them, or use a type abstraction that can infer the proper type from the propType.

wow! I didn’t know about those use cases and also these are what I am missing in typescript world and wish I had! I am looking forward to use those in my code after this bug gets fix. thanks.

saostad on Mar 10, 2020