-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds new no-unused-prop-types
rule
#611
Conversation
I found one condition where this reports a false positive: class Hello extends Component {
static propTypes = {
params: PropTypes.shape({
id: PropTypes.string
})
}
render () {
const {params} = this.props;
const id = (params || {}).id;
return <span>{id}</span>;
}
} Not sure yet how to get EDIT: I think trying to resolve it will be a losing battle of whack-a-mole. As such, I have added an |
I'm going to have a look at this now but want to flag to @EvNaverniouk that the PR has conflicts. Can you fix @EvNaverniouk ? I think the issue using the pattern |
Merged master into this PR to resolve conflicts. Thanks @mattdell |
@EvNaverniouk it'd be nice if you could rebase master instead, so there's no merge commits (and to squash all the "wip" commits) |
46462cc
to
74f0cbe
Compare
@ljharb Rebased. |
What needs to happen to get this merged? |
looks like it needs another merge / rebase |
@EvNaverniouk would you mind rebasing this? |
7b9fdb6
to
6bbb9f3
Compare
@ljharb Rebase completed. |
ping @yannickcr :-) |
@EvNaverniouk do you plan to fix conflicts? |
I resolved the conflicts between this branch and master and pushed them to my fork: antialias@dffa1f3 There were no ambiguities, i.e. I'm 100% confident that I resolved them correctly. @yannickcr, I could submit a replacement PR or @EvNaverniouk, you could hard reset this branch to the commit from my branch and the PR would show as resolved. |
6bbb9f3
to
e2dbee2
Compare
Looks like some of my tests are failing after merging from latest master. Investigating... |
Ok. Fixed the conflicts and rebased again. Also added a new commit to fix a bug in the |
// Rule Definition | ||
// ------------------------------------------------------------------------------ | ||
|
||
module.exports = Components.detect(function(context, components, utils) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should use the new eslint rule format
@petersendidit Updated PR to use new ESLint rule format. |
I pulled down this branch into one of my projects to give it a try, since I'm really excited about this - it worked great, except for in one component where it did not detect that I was only using a prop in |
@dhruska Can you send me a copy of the code that reproduces that? |
@EvNaverniouk Let me work on getting you an example. I tried to create a simple component that would reproduce the issue and was not able to. |
this will be very useful! I'll try to test this on our codebase (1M+ lines) and report back |
} | ||
}); | ||
|
||
function Hello({ name }) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why this is included in the examples--this component has no propTypes. Did you mean to include something like this?
Hello.propTypes = {
name: React.PropTypes.string.isRequired,
};
abd522f
to
504bcd5
Compare
@lencioni Updated PR to clean up the docs as per your recommendations, fixed merge conflicts and rebased. |
I think this looks good, thanks for all of your work on this rule. If this code is based off of the prop-types rule code, we currently have a bug in that rule where nested destructured props are not marked as used. (#296) It would be good to include some examples in your tests that demonstrate this. |
504bcd5
to
f083a13
Compare
@lencioni Not sure if that's what you had in mind, but I added a commented-out test at f083a13#diff-655c668b4b1964c5be4ff486d879ef45R1980 which can be enabled once #296 is fixed. |
@EvNaverniouk Thanks for doing that! That's not quite what I had in mind. My point was more that if we are introducing code that has bugs that we are aware of, it would be nice to fix those bugs before merging. And actually, I think the bug might be the inverse in this rule (e.g. nested destructuring of a prop in propTypes is incorrectly flagged). function Foo(props) {
const { foo: { bar } } = props;
return <div test={bar} />;
}
Foo.propTypes = {
foo: PropTypes.shape({
bar: PropTypes.number,
}),
}; Any chance you can add a test case for this, and if it fails, make it pass? |
I think this rule already adds a lot of value even if this bug is not fixed right now. So I am not against merging this rule with the bug and fix it later on (actually I still need to figure out how to fix it in the Also I'd prefer to name this rule |
Ho, and thank you for this @EvNaverniouk, this is really great work ❤️ |
b2c8cf5
to
8be951a
Compare
unused-prop-types
ruleno-unused-prop-types
rule
@lencioni To be honest with you, fixing that bug is a bit beyond my level of understanding of how the component and proptype detection works. However, I'm happy to merge the fix in into this rule once someone solves that bug for the @yannickcr I've renamed the rule to |
@EvNaverniouk Perfect is the enemy of the good, so that sounds good to me. Thanks for your work on this! |
Merged, thanks! |
thank you guys, nice rule and nice job |
@yannickcr: I updated to 6.2.2 and added rule as following: Something I'm missing here? |
@tristanbbq Can you please open a new issue with a code sample I can use to reproduce? |
@EvNaverniouk: just created #837 |
Fixes #226 by adding an new
unused-prop-types
rule.The rule is based very heavily on the
prop-types
rule and shares a lot of the same code. For the time being, I have not made any attempts at breaking out the shared code into a reusable utility file. Please advise on the best way to do this. I was simply thinking of dropping aproptypes.js
file into theutils
directory with all the shared functions. If that's acceptable, let me know and I will do that.Have tested against several React projects with great success so far. No false positive problems yet, but it needs a lot more testing against other repos. I'm hoping other users will report issues as they try it. For my needs, this rule is working great.
Can be tested by following these steps:
Then enable the rule in your eslintrc: