Support all possible key shortcuts other than the Enter key

[mehm8128]

The slide that this rule is based on discusses issues with the shortcut keys other than Enter key, such as Tab key on Slack.
https://ef81sp.github.io/ime-vs-input-keyboard-shortcut/11?clicks=6

So, I think this rule can extends to all possible key shortcuts other than Enter key.

And for Enter key shortcut, it'll be good to support not only e.isComposing but also Ctrl or Meta key explained in the Solution 2 slide.
https://x.com/almaximal/status/2044858152592568555?s=20

[mehm8128]

Related to this issue, I realized that keydown event handler can be attached to any HTML element other than input or input-like (for example textarea) element and when users are focusing such HTML elements, IME shortcut keys problem doesn't occur.
So we may not want to show warning to such cases:

<div
    tabindex={0}
    role="button"
    onClick={(e) => someAction()}
    onKeyDown={(e) => {
      if (e.key === "Enter") {
        someAction();
      }
    }}
  />

It may be difficult to implement it on addEventListener pattern because we can't know what HTML element the given node is, but for the pattern that onKeyDown event handler is directly passed to HTML element (or React component, but this pattern need option to have this ESLint rule know the relationship of React component and its parent HTML element), we can ensure that only input or input-like elements are checked.

[hiroya-uga]

@mehm8128 Thank you for opening this issue!

Great point! This is a valid improvement — for non-input HTML elements like <div tabindex={0}>, IME composition can't occur, so the rule shouldn't flag them.

However, one thing worth noting: <div contenteditable> (and contenteditable="true") also accepts IME input, so it should still be treated as an input-like element and flagged alongside <input> and <textarea>.

For the implementation, I'm thinking:

• Warn: <input>, <textarea>, <select>, elements with a contenteditable attribute
• Skip: <div>, <button>, <span>, etc. (no contenteditable)
• Warn by default: PascalCase components (<MyInput>) — the rule can't inspect the rendered output; an allowComponents option could allow users to opt out

For addEventListener and element.onkeydown, the target element is unknown statically, so the current behaviour would stay as-is.

I'll need some more time to think through the details before moving forward with the implementation.

[mehm8128]

That's right, I overlooked contenteditable pattern.
Draft PR for Biome to port this rule has been created, so it'll also be valuable to discuss these cases with Biome team.
feat(lint): add noComposingEnterKey rule by siketyan · Pull Request #10042 · biomejs/biome

[hiroya-uga]

Thanks for the detailed report!

Here's what I'm planning to tackle:

1. Modifier key support — e.ctrlKey && e.key === 'Enter' and similar patterns should be IME-safe since modifiers prevent IME composition. ✅ Done in v1.1.1
2. Non-input element scoping — <div role="button"> and similar elements can't receive IME input, so they shouldn't be flagged. <div contenteditable> is an exception and should still be flagged. → v1.2.0
3. Non-Enter key support — Tab and other keys have the same IME race condition. → v1.2.0

[hiroya-uga]

All items raised in this issue have been addressed:

v1.2.0 — Modifier key guard support

• if (e.key === 'Enter' && e.ctrlKey) and similar patterns are now recognised as IME-safe (Ctrl/Meta/Shift/Alt held → composition cannot be active)
• Outer if (e.ctrlKey) { if (e.key === 'Enter') … } pattern is also recognised

v1.3.0 — All key checks beyond Enter

• The rule now flags any key property check (e.key, e.code, e.keyCode, e.which) without an e.isComposing guard, not just Enter
• Escape, Tab, ArrowDown, and all other keys on IME-capable elements are covered
• JSX handlers on non-IME-capable elements (<div>, <button>, etc.) are excluded via element scoping

Thanks for the great reference slides and the feature request!