Eslint-plugin-react: no-typos rule doesn't handle custom proptypes classes

[modosc]

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.

[jseminck]

Just for information, indeed we added logic to validate the specific PropTypes. Since string is a key that is exported from the official prop-types package, it doesn't fail. bar is not a prop type defined in the official prop-types package, so it fails.

Not sure how we should handle this case yet. Just explaining what changes and why the error is introduced. 😄

[ljharb]

This seems like a bug in no-typos - we should only be looking for typos on React.PropTypes or on an import/require of prop-types.

[jseminck]

I'm trying to work on this... I guess we need to support the following cases? Did I miss anything?

import PropTypes from "prop-types"

import { PropTypes } from "react";

import { PropTypes as ValidPropTypes } from "react"

import React from "react"
React.PropTypes

[ljharb]

@jseminck also require('prop-types') in any form.

[martin-svk]

It also fails when importing specific prop types directly:

import { func, number } from 'prop-types';

MyComponent.propTypes = {
    funcProp: func.isRequired,
    numberProp: number.isRequired
};

Resulting in react/no-typos Error.

[oieduardorabelo]

same happens when using react-intl inject hoc:

import { injectIntl, intlShape } from "react-intl";

function Example() { //code }

Example.propTypes = {
  // ESLint error: 'Typo in declared prop type: isRequired (react/no-typos)'
  intl: intlShape.isRequired
};

export default injectIntl(Example)

you can ignore the line number in the screenshot, is just an example

[felpin]

Well, this does not resolve the issue, but you can disable a rule in ESLint with a comment

Foo.propTypes = {
  // eslint-disable-next-line react/no-typos
  bar: MyPropTypes.string.isRequired
}

In this particular case I do that while this issue is open

[neiker]

Same using react-immutable-proptypes

[zxlin]

@jseminck

Another case where webpack's ProvidePlugin is used to avoid repetitively importing prop-types everywhere.

In my code I don't import prop-types explicitly and simply write:

const { string, object } = PropTypes;

and get the validators that way as webpack will replace all instances of PropTypes with the prop-types module.

[ljharb]

@zxlin using webpack to get magic implicit imports isn't necessarily a use case we should be handling or encouraging, imo.

[the-noob]

Adding this for whoever looks for MobX no-typos error :)

import { observer, inject, PropTypes as MobXPropTypes } from 'mobx-react';

class App extends React.Component { ...}

App.wrappedComponent.propTypes = {
  appStore: MobXPropTypes.objectOrObservableObject.isRequired,
};

Produces

Typo in declared prop type: objectOrObservableObject react/no-typos

[jseminck]

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.

[ljharb]

@jseminck also React.PropTypes, hopefully :-)

[Kenjirou]

Same typo-error for ReactNative's style proptypes:

import PropTypes from 'prop-types';
import {View} from 'react-native';

CoolComponent.propTypes = {
    containerStyle: View.propTypes.style,
};

[abdennour]

@jseminck , any update ? we are waiting ☕️

[Hypnosphi]

@abdennour you can make your own PR if you feel like it

[jseminck]

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.

[extwiii]

any update ? we are waiting ☕️

[alex-shamshurin]

Yes, I have the same issue. It works inside React.component extended class and doesn't work for stateless components

[Koleok]

I just need to drop a note on the repeated toe-tapping scoldy comments in this thread

_ie:_

_any update? we are waiting ☕️_

Github automatically posts references for:

• opens/closes/merges on related MRs
• commits with references to this issue
• references to this issue from other issues

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

_"hey i need this to work right now how long till you fix it!"_

then guess what, you my friend are ready to be an open source contributor.

You might say:

_"I don't know how this library works!"_

well, read the source, and soon you will

_"i don't have time my job is relentless and I'm being pressured"_

well, so are the maintainers you are pressuring, probably more so!

_"No one has committed anything in a long time and i fear the project is abandoned :scream:"_

well, fork it and do it your way, or just be patient :)

[dkrutsko]

Hey everyone, I'd like to add two additional pieces of information regarding this issue:

1. Since PR #1652 it seems that no-typos started 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.

2. For this issue specifically, I'm guessing that all that needs to change is this variable? Would mutating it through props solve the issue?

[brettdh]

@jseminck how critical is it to have the behavior in the failing test? Your branch resolves my issue perfectly; I bet that's the case for a lot of folks here. The "renamed React import" seems like a very small corner case; I'd suggest breaking off a new issue for just that, and focus on getting the awesome work you've already done merged.

Since I'm invested in this now, I'll remove that test and create a PR. If this isn't acceptable, I'm sure the reasons will be discussed there. :)

@dkrutsko could you be a little more specific about what you think the fix is? Are you referring to the failing test @jseminck mentioned above, or are you suggesting that the fix for this entire issue is somehow much simpler than @jseminck 's changes?

If necessary, I'm happy to add your suggestions to my forthcoming PR.

[dkrutsko]

@brettdh It appears that the "valid" prop-types are retrieved using Object.keys (require ('prop-types')). I'm guessing that making this variable user editable through the linter settings would allow anybody to add additional prop-types. Like in my case, I'd like an option to add more prop-types on top of the existing ones in the package.

[brettdh]

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:

1. Correctly specified custom proptypes should not cause no-typos errors (this issue)
2. Custom proptypes with typos should cause no-typos errors (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?

[wpwood]

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:

const linkShape = PropTypes.shape({
  text: PropTypes.string,
  url: PropTypes.string,
})

FooterLinks.Link.propTypes = {
  link: linkShape.isRequired,
}

This rule gives the Typo in declared prop type: isRequired react/no-typos error.