[New] checkContextObjects option in display-name

[JulesBlm]

I'm proposing adding a new rule that checks if the displayName property is set for context objects, see Context.displayName in the React docs.

With multiple Context providers in an app, consistently setting a displayName makes it easy to see which is which in the React dev tools.

Some things to consider

• Should it perhaps be part of the display-name rule instead of a separate rule?
• Does it need more tests?
• Does this checking approach make sense? (This is my first time writing an ESLint rule, so I wouldn't be surprised if this is not the best way)
• Does it need to check more cases?

[codecov]

Codecov Report

Merging #3529 (725d4c7) into master (abb4871) will increase coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head 725d4c7 differs from pull request most recent head a684ae1. Consider uploading reports for the commit a684ae1 to get more accurate results

@@            Coverage Diff             @@
##           master    #3529      +/-   ##
==========================================
+ Coverage   97.58%   97.59%   +0.01%     
==========================================
  Files         131      132       +1     
  Lines        9236     9289      +53     
  Branches     3358     3394      +36     
==========================================
+ Hits         9013     9066      +53     
  Misses        223      223              

Impacted Files	Coverage Δ
lib/rules/display-name.js	98.57% <100.00%> (+0.23%)	⬆️
lib/util/isCreateContext.js	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[ljharb]

Overall, this seems reasonable. Should this maybe be an option on the display-name rule?

[JulesBlm]

Overall, this seems reasonable. Should this maybe be an option on the display-name rule?

I think that makes sense, the intention is the same. Main difference is that createContext does not create a component directly but a context object containing two components.
I looked at the implementation of display-name and it makes heavy use of the Components utility, which can't be used for createContext. I thought it would be easier and cleaner to make a separate rule for it but I'm not married to the idea of it being a separate rule. What would your preference be?

[ljharb]

while that's a fair point, since the rule is "display name" and not "component display name" i think it's worth figuring out the complexity inside the rule, rather than adding complexity for users.

[JulesBlm]

while that's a fair point, since the rule is "display name" and not "component display name" i think it's worth figuring out the complexity inside the rule, rather than adding complexity for users.

Alright makes sense, I turned it into a checkContextObjects option in display-name. As far as I can tell, the logic for detecting component isn't of much use for detecting context definitions so I chose not make use of the Components utility for it.

[ljharb]

There's a few lines missing test coverage; otherwise it looks pretty great!

[JulesBlm]

There's a few lines missing test coverage; otherwise it looks pretty great!

Thanks! I noticed I forgot to enable the new flag for the new valid tests so I added that. I added few more tests too, some formatting fixes and moved the React version check.

I'm a little confused how to increase the test coverage. What would need to be done to meet the threshold? Test the isCreateContext util?

[ljharb]

Looks good overall

[JulesBlm]

Hey, is there anything I can do to move this PR forward?

[ljharb]

@JulesBlm sorry for the delayed reply; i replied to your comment above and will review today.

[ljharb]

This looks great - I'll land this later tonight.

[JulesBlm]

Awesome thanks for your review @ljharb!

[christianvuerings]

@ljharb Would you be able to push out a release with this feature?

[ljharb]

v7.33.0 is released.

[christianvuerings]

@ljharb https://www.npmjs.com/package/eslint-plugin-react still shows 7.32.2 as the latest version. Did anything go wrong during the npm publish process?

[ljharb]

huh, maybe so, let me check

[ljharb]

ah thanks, published it manualy

[christianvuerings]

@ljharb that worked, thank you!