This package contains an eslint plugin that enforces some default rules for using EUI.
npm install @elastic/eslint-plugin-eui@elastic/eslint-plugin-euiThis package contains an eslint plugin that enforces some default rules for using EUI.
1. Install @elastic/eslint-plugin-eui as a dev dependency.
2. Extend plugin:@elastic/eui/recommended in your ESLint config.
should either be a button or a link, for a11y purposes. When given an href the button behaves as a link, otherwise an onClick handler is expected and it will behave as a button.
In some cases it makes sense to disable this rule locally, such as when cmd + click should open the link in a new tab, but a standard click should use the history.pushState() API to change the URL without triggering a full page load.
At times, we deprecate features that may need more highlighting and/or that are not possible to annotate with JSDoc @deprecated, e.g. JSON token imports: @elastic/eui/dist/eui_theme_*.json (for context: https://github.com/elastic/kibana/issues/199715#json-tokens).
We don't use no-restricted-imports because ESLint doesn't allow multiple error levels at once and it may conflict with the consumer's existing ESLint configuration for that rule. We need to assure that our rule will produce a warning (as a recommendation).
All deprecations still must follow our deprecation process.
This rule warns engineers to not use literal css color in the codebase, particularly for CSS properties that apply color to either the html element or text nodes, but rather urge users to defer to using the color tokens provided by EUI.
This rule kicks in on the following JSXAttributes; style, className and css and supports various approaches to providing styling declarations.
#### Example
The following code:
``tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { EuiText } from '@elastic/eui';
function MyComponent() {
return (
)
}
`
`tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { EuiText } from '@elastic/eui';
function MyComponent() {
const style = {
color: 'red'
}
return (
)
}
`
`tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { EuiText } from '@elastic/eui';
function MyComponent() {
const colorValue = '#dd4040';
return (
)
}
`
will all raise an eslint report with an appropriate message of severity that matches the configuration of the rule, further more all the examples above
will also match for when the attribute in question is css. The css attribute will also raise a report the following cases below;
`tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { css } from '@emotion/css';
import { EuiText } from '@elastic/eui';
function MyComponent() {
return (
}>You know, for search
)
}
`
`tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { EuiText } from '@elastic/eui';
function MyComponent() {
return (
)
}
`
A special case is also covered for the className attribute, where the rule will also raise a report for the following case below;
`tsx
// Filename: /x-pack/plugins/observability_solution/observability/public/my_component.tsx
import React from 'react';
import { css } from '@emotion/css';
import { EuiText } from '@elastic/eui';
function MyComponent() {
return (
}>You know, for search
)
}
`
It's worth pointing out that although the examples provided are specific to EUI components, this rule applies to all JSX elements.
Ensure that EUI modal components (EuiModal, EuiFlyout, EuiFlyoutResizable ,EuiConfirmModal) have either an aria-label or aria-labelledby prop for accessibility. This helps screen reader users understand the purpose and content of modal dialogs.
Ensure that form control components within EuiFormRow components have matching isInvalid prop values. This maintains consistent validation state between parent form rows and their child form controls, leading to a more predictable and accessible user experience.
Ensure disableScreenReaderOutput is set when EuiToolTip content matches EuiButtonIcon "aria-label".
Ensure EuiIconTip is used rather than , as it provides better accessibility and improved support for assistive technologies.
Ensure that all radio input components (EuiRadio, EuiRadioGroup) have a name attribute. The name attribute is required for radio inputs to be grouped correctly, allowing users to select only one option from a set. Without a name, radios may not behave as expected and can cause accessibility issues for assistive technologies.
Ensure that EuiCallOut components rendered conditionally have the announceOnMount prop for better accessibility. When callouts appear dynamically (e.g., after user interactions, form validation errors, or status changes), screen readers may not announce their content to users. The announceOnMount prop ensures these messages are properly announced to users with assistive technologies.
Ensure that appropriate aria-attributes are set for EuiBetaBadge, EuiButtonIcon, EuiComboBox, EuiSelect, EuiSelectWithWidth,EuiSuperSelect,EuiPagination, EuiTreeView, EuiBreadcrumbs. Without this rule, screen reader users lose context, keyboard navigation can be confusing.
Ensure EuiTooltip components are anchored to elements that can receive keyboard focus, making them accessible to all users. When using non-interactive elements (like spanor EuiText) as tooltip anchors, they must include tabIndex={0} to be keyboard-focusable. For better accessibility, prefer using semantic interactive components (like EuiButton or EuiLink) which are focusable by default.
Ensure interactive EUI components (like e.g. EuiLink, EuiButton, EuiRadio) remain accessible by prohibiting tabIndex={-1}, which removes them from keyboard navigation.
Ensure EuiInMemoryTable, EuiBasicTable have a tableCaption property for accessibility.
Run unit tests using the following command:
`bash`
yarn test
Unit tests are written using RuleTester from @typescript-eslint/rule-tester.
To test the local changes to the plugin, you must:
1. Install yalc globally if you haven't already: npm install -g yalc.cd packages/eslint-plugin
2. Open a terminal and navigate to this folder: yarn build
3. Build the package: yalc publish
4. Run in the plugin's directory to publish it locally.yalc add @elastic/eslint-plugin-eui
5. In your project's directory, run to link the locally published package.yarn
6. Install dependencies: (if you're a Kibana contributor, run yarn kbn bootstrap --no-validate`).
7. After making further changes to the plugin, repeat the steps from 3.
Refer to the wiki for instructions on how to release this package.