[eslint-plugin] Added new @elastic/eui/no-nested-copy-tooltip rule

[alexwizp]

Summary

• What: Adds a new ESLint rule @elastic/eui/no-nested-copy-tooltip and updates the existing @elastic/eui/tooltip-button-icon-wrap rule to avoid a conflict between the two.
• Why: EuiCopy already wraps its render-prop child in an EuiToolTip internally, using the beforeMessage prop as that tooltip's content. When the render-prop child is itself an EuiToolTip, the result is a nested, conflicting tooltip. The new rule flags this pattern; the tooltip-button-icon-wrap update prevents it from demanding a wrapper that no-nested-copy-tooltip forbids.
• How:
  • no-nested-copy-tooltip (a11y): reports when EuiCopy sets beforeMessage and its render-prop root child is an EuiToolTip, recommending removal of the EuiToolTip wrapper and moving its message into beforeMessage. It resolves the render-prop root through implicit arrow returns, block-body return statements (including block bodies with an early return), and function expressions. It is report-only (no autofix), because the tooltip's content and an existing beforeMessage value cannot always be merged safely (e.g. when either is a variable or JSX).
  • tooltip-button-icon-wrap: added an EuiCopy ancestor exception so an EuiButtonIcon rendered inside an EuiCopy that sets beforeMessage is no longer flagged for a missing EuiToolTip wrapper (the tooltip is provided by EuiCopy). Without beforeMessage there is no tooltip, so the button is still flagged. A browser-native title prop is still reported in all cases.
  • Registered the new rule in src/index.ts (recommended config, warn level), added tests, and updated the plugin README.md.

API Changes

component / parent	prop / child	change	description
@elastic/eslint-plugin-eui	no-nested-copy-tooltip	Added	New a11y rule flagging EuiCopy + beforeMessage with an EuiToolTip render-prop child
@elastic/eslint-plugin-eui	tooltip-button-icon-wrap	Changed	No longer requires an EuiToolTip wrapper for an EuiButtonIcon rendered inside an EuiCopy that sets beforeMessage

No changes to the @elastic/eui component public API.

Screenshots

N/A — lint-only change, no visual output.

Impact Assessment

Note: Most PRs should be tested in Kibana to help gauge their Impact before merging.

• 🔴 Breaking changes — None.
• 💅 Visual changes — None (lint-only).
• 🧪 Test impact — The new rule ships in the recommended config at warn level, so consumers (e.g. Kibana) may see new lint warnings where EuiCopy + beforeMessage wraps an EuiToolTip. Warnings only — no build breakage.
• 🔧 Hard to integrate — No.

Impact level: 🟢 Low

Release Readiness

• Documentation: packages/eslint-plugin/README.md (rule docs with examples for both rules)
• Figma
• Migration guide — new warn-level rule, no migration required
• Adoption plan — enabled via the existing recommended config

QA instructions for reviewer

• Run yarn test in packages/eslint-plugin.
• Confirm no_nested_copy_tooltip.test.ts passes (valid/invalid cases for implicit return, expression beforeMessage, block-body return, function expression, and early return).
• Confirm tooltip_button_icon_wrap.test.ts passes, including the new EuiCopy exception cases (with and without beforeMessage) and that a title prop inside EuiCopy is still reported.

Checklist before marking Ready for Review

• Filled out all sections above
• QA: light/dark modes, high contrast, mobile, browsers, keyboard, screen reader — lint-only change
• QA: Tested in CodeSandbox and Kibana
• QA: Tested docs changes
• Tests: Added/updated Jest tests
• Changelog: Added changelog entry
• Breaking changes: label — not applicable

Reviewer checklist

• Approved Impact Assessment — Acceptable to merge given the consumer impact.
• Approved Release Readiness — Docs and migration info are sufficient to ship.

[alexwizp]

A question for the reviewers: should this be considered a problem? I don't think so—perhaps it can be allowed for the sake of flexibility.

[weronikaolejniczak]

This pattern works reliably. The issue would be if both beforeMessage and child EuiToolTip existed. Because we no longer bubble events as of v118.0.0, only the innermost tooltip shows (most often the EUI internal one that consumers should be able to override with a prop, as is the case with EuiCopy).

I don't see any issue with this composition. And linting should get rid of any ambiguity anyway because of a developer/an agent see this pattern somewhere, decide to use it but with beforeMessage, the linter will flag it.

[Copilot]

Pull request overview

Adds a new a11y-focused ESLint rule to prevent nested/conflicting tooltips when EuiCopy is used with beforeMessage, and updates the existing tooltip-button-icon-wrap rule/docs/tests so the two rules don’t fight each other.

Changes:

• Added new @elastic/eui/copy-component-rules rule (report-only) to flag EuiCopy + beforeMessage when the render-prop returns an EuiToolTip as the root element.
• Updated @elastic/eui/tooltip-button-icon-wrap to exempt EuiButtonIcon inside EuiCopy from the “must be wrapped in EuiToolTip” report.
• Registered the new rule in the plugin’s recommended config, and updated tests/docs/changelog.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
packages/eslint-plugin/src/rules/a11y/tooltip_button_icon_wrap.ts	Adds EuiCopy ancestor exception to avoid requiring a wrapper tooltip that would conflict with the new rule
packages/eslint-plugin/src/rules/a11y/tooltip_button_icon_wrap.test.ts	Adds test coverage for the new EuiCopy exception behavior (and title reporting)
packages/eslint-plugin/src/rules/a11y/copy_component_rules.ts	Introduces the new rule detecting redundant EuiToolTip wrapping inside EuiCopy when beforeMessage is set
packages/eslint-plugin/src/rules/a11y/copy_component_rules.test.ts	Adds valid/invalid rule tests for implicit and explicit render-prop returns
packages/eslint-plugin/src/index.ts	Registers the new rule and enables it in recommended at warn level
packages/eslint-plugin/README.md	Documents the new rule and the updated tooltip-button-icon-wrap exception
packages/eslint-plugin/changelogs/upcoming/9852.md	Adds changelog entry for the new rule and the exception update

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[weronikaolejniczak]

@alexwizp ESLint plugin tests are finally resolved in CI: https://buildkite.com/elastic/eui-pull-request-test/builds/7051#019fae26-2f8a-4b88-9fe5-73f34d49660d 🎉 So no need to run them locally, if CI is 🟢 then we're good.

[weronikaolejniczak]

@kapral18 could you also take a look at it since you raised this? 🙏🏻

[weronikaolejniczak]

No action required: I was thinking if this should be a "suggestion" instead because it's a warning and there's no issue at runtime but it will produce an undesired result to what was coded, so I'm fine categorizing it as a "problem".

[weronikaolejniczak]

This whole PR looks great to me, thank you for tackling it, @alexwizp 🙏🏻 You're a champ!

I see there are only 8 violations in Kibana. All of them use an arrow function expression. There's one potential case we could handle too that won't be flagged, an early return:

<EuiCopy beforeMessage="Click to copy" textToCopy="some text">
  {(copy) => {
    if (!condition) return null;
    return <EuiToolTip content="Copy me"><EuiButton onClick={copy}>Copy</EuiButton></EuiToolTip>;
  }}
</EuiCopy>

[kapral18]

Leaving a few edge cases around the new static checks. cc: @weronikaolejniczak for a quick glance as well.

[kapral18]

Minor/nit: the spread handling is asymmetric between the two components here.

hasSpread skips the report when the EuiButtonIcon itself has spread props, on the grounds that its final prop set is not statically knowable. But beforeMessage can arrive on EuiCopy the same way:

<EuiCopy textToCopy="x" {...props}>
  {(copy) => <EuiButtonIcon aria-label="Copy" iconType="copy" onClick={copy} />}
</EuiCopy>

isInsideEuiCopyWithBeforeMessage returns false here and the button is reported, even though props may well carry beforeMessage. Worth applying the same "can't statically determine" treatment to a spread on the EuiCopy ancestor, or noting explicitly that unknown spread is intentionally treated as absent.

[kapral18]

Withdrawing this one — you're right it isn't worth the complexity. Silently skipping unknown spread is already the convention across this plugin, and Kibana's a11y docs list it as an expected manual-review caveat for this rule. Resolving.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 4a4fece

History

• 💚 Build #7230 succeeded 94bb7f3
• 💚 Build #7226 succeeded f905cca
• 💚 Build #7225 succeeded 04ecd33
• 💚 Build #7224 succeeded 840f2a5
• 💚 Build #7222 succeeded 024ca00
• 💚 Build #7221 succeeded 1c96cec

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 4a4fece
• Documentation website
• Storybook
• 🚫 Visual regression tests skipped (remove the skip-vrt label to re-enable)

History

• 💚 Build #4478 succeeded 94bb7f3
• 💚 Build #4474 succeeded f905cca
• 💚 Build #4472 succeeded 04ecd33
• 💚 Build #4471 succeeded 840f2a5

[alexwizp]

@kapral18 could you review it again? I'm a bit skeptical about fixing very specific edge cases in the static analyzer. It seems to me that the important thing here is to strike a balance between real-world and hypothetical cases. Thanks

[kapral18]

LGTM — all three findings fixed, and hasMeaningfulAttr is a better shape than what I suggested: component-agnostic and separately tested. Verified the repros on 4a4fece, including that meaningful/dynamic beforeMessage still behaves as before. Suites green.

On balance vs. hypotheticals: agreed, and I've withdrawn both remaining edge cases. The motivating Kibana case is pivot_function_form.tsx, which carries an eslint-disable for tooltip-button-icon-wrap today — this PR lets us delete it.

[weronikaolejniczak]

LGTM! 🟢 Thank you both 🙏🏻