eslint-plugin-react: no-typos rule doesn't handle custom proptypes classes
with the 7.2.1 -> 7.3.0 upgrade this rule started breaking on this code:
import * as MyPropTypes from 'lib/my-prop-types'
const Foo = ({ bar } = {} ) => <div className={bar} />
Foo.propTypes = {
bar: MyPropTypes.bar.isRequired
}
with
29:25 error Typo in declared prop type: bar react/no-typos
interestingly enough if i change to this:
Foo.propTypes = {
bar: MyPropTypes.string.isRequired
}
then the rule passes, even though MyPropTypes doesn’t export a string prop.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 60
- Comments: 25 (11 by maintainers)
I just need to drop a note on the repeated toe-tapping scoldy comments in this thread
ie:
Github automatically posts references for:
These are the updates you are looking for.
It is not, and should not be the responsibility of anyone involved in an OSS project to look through each issue every day and copy/paste links to commits or give progress reports to impatient/unmotivated consumers of the library.
The whole point of open source, is that maintainers do things when they can, and contributors who have time step in and fill the gaps when they can.
If you find yourself continually posting things in github issues like
then guess what, you my friend are ready to be an open source contributor.
You might say:
well, read the source, and soon you will
well, so are the maintainers you are pressuring, probably more so!
well, fork it and do it your way, or just be patient 😃
any update ? we are waiting ☕️
It also fails when importing specific prop types directly:
Resulting in
react/no-typosError.@abdennour you can make your own PR if you feel like it
@jseminck , any update ? we are waiting ☕️
Same using
react-immutable-proptypessame happens when using
react-intlinject hoc:you can ignore the line number in the screenshot, is just an example
Same typo-error for ReactNative’s style proptypes:
I’m working on this, so that custom PropTypes imports will be ignored and only the real “prop-types” package will be considered for checking typos.
Ah, yep - that makes sense. I think I was confused by the overloaded term “prop” in your comment. 😃
I think that’s also a separate issue from this one. That is, I see two separable desired behaviors:
no-typoserrors (this issue)no-typoserrors (your request)I can see why the second is valuable, but the first strikes me as higher-impact. Thus, I’d suggest you make a new issue to track just the second, as it seems ever so slightly out of scope for this one.
Sound reasonable?
I have a branch here: https://github.com/jseminck/eslint-plugin-react/tree/no-typos-react-import
It still has a failing test - but if you have any ideas feel free to help. If you want to finish it then you’re free to take this code and continue working on top of it.
This turned out harder than I thought. Didn’t even work with
require()yet 😞Furthermore the React/PropTypes import code should probably be extracted to an util because other rules could also benefit from it.
@zxlin using webpack to get magic implicit imports isn’t necessarily a use case we should be handling or encouraging, imo.
Well, this does not resolve the issue, but you can disable a rule in ESLint with a comment
In this particular case I do that while this issue is open
I think i may have another case where this is failing. When the shape is defined in the same file where it’s used, it’s failing. I have a file with two components, sharing a shape. Something like this:
This rule gives the
Typo in declared prop type: isRequired react/no-typoserror.Adding this for whoever looks for MobX no-typos error 😃
Produces
Hey everyone, I’d like to add two additional pieces of information regarding this issue:
Since PR #1652 it seems that
no-typosstarted detecting more issues! However, While this rule detects “invalid” propTypes defined in functional components, it doesn’t work inside classes when defining propTypes through static instance variables.For this issue specifically, I’m guessing that all that needs to change is this variable? Would mutating it through props solve the issue?
Just for information, indeed we added logic to validate the specific PropTypes. Since
stringis a key that is exported from the officialprop-typespackage, it doesn’t fail.baris not a prop type defined in the officialprop-typespackage, so it fails.Not sure how we should handle this case yet. Just explaining what changes and why the error is introduced. 😄
@jseminck
Another case where webpack’s
ProvidePluginis used to avoid repetitively importingprop-typeseverywhere.In my code I don’t import
prop-typesexplicitly and simply write:and get the validators that way as webpack will replace all instances of
PropTypeswith theprop-typesmodule.