jsx-key rule should error on returning short hand fragments (<>) from iterators to avoid false negative

[GNRSN]

Issue

Mapping a list into multiple components per list element, surrounding them with jsx shorthand fragments <> currently results in no eslint error with jsx-key rule enabled, even though React will warn/error about missing keys.

According to the documentation, the recommendation is to instead always return full fragments from iterators, i.e.

<Fragment key={key}>
   ...
</Fragment>

See the short section in: https://react.dev/reference/react/Fragment#rendering-a-list-of-fragments

Suggestion

With the jsx-key rule enabled, shorthand fragments returned from an iterator should still error without key, fix could update to <React.Fragment key={key}>

Motivation

Since missing keys can be pretty hard to debug, especially on fragments which won't show up in devtools, having eslint help with this would be extremely valuable instead of having to debug once it hits staging.

Misc

#2365 seems to be the most recent issue on this topic, discussing the removal of key requirement for shorthand fragments as they don't support it

[ljharb]

These are arrays, not iterators, to be clear.

#2365 is explicitly about fixing the error message when fragment shorthand is used - meaning, it does error.

It can’t be auto fixed because we can’t pick the key for the developer.

Can you provide a repro repo where it doesn’t error?

[GNRSN]

@ljharb Here is a minimal repro built on create-vite-app

https://github.com/GNRSN/eslint-plugin-react-shorthand-fragment-no-missing-key-error/blob/main/src/Repros.jsx

[ljharb]

@GNRSN are you perhaps unaware that there's a checkFragmentShorthand option that's not enabled by default? When I enable it, it works fine.

You shouldn't use "recommended" configs, including ours - you should use the airbnb config.

[GNRSN]

@ljharb Thank you for pointing out my ignorance, as usual, the answer was in the documentation.

I'm phasing in stricer lint rules in a large legacy code-base so starting out with the Airbnb config (which is from my limited experience with it, extremely strict) isn't really an option.

[ljharb]

I’d suggest starting with the Airbnb config and using overrides initially to allow existing files to violate whatever, and then gradually remove the overrides. That way, new files are in compliance.