Getting Started with ESLint Plugin

eds-eslint-plugin is an ESLint plugin for teams consuming the Design system. It catches deprecated API, wrong import paths and missing accessible names at lint time, before code review.

pnpm add -D @adaptavant/eslint-plugin-eds

The plugin ships rules only. It sets no parser, so keep your own: TypeScript and TSX files still need @typescript-eslint/parser, and JSX needs ecmaFeatures: { jsx: true }. flat/recommended scopes itself to .ts, .tsx, .js, .jsx, .mts, .cts, .mjs and .cjs.

Flat config (eslint.config.js, or eslint.config.mjs unless your package.json sets "type": "module"):

import edsPlugin from '@adaptavant/eslint-plugin-eds';

export default [edsPlugin.configs['flat/recommended']];

Legacy eslintrc (.eslintrc.json):

{
  "extends": ["plugin:@adaptavant/eds/recommended"]
}

To pick rules or change severities yourself:

import edsPlugin from '@adaptavant/eslint-plugin-eds';

export default [
  {
    plugins: { '@adaptavant/eds': edsPlugin },
    rules: {
      '@adaptavant/eds/no-deprecated-props': 'error',
      '@adaptavant/eds/no-restricted-eds-imports': 'error',
      '@adaptavant/eds/require-icon-button-aria-label': 'error',
      '@adaptavant/eds/no-deprecated-components': 'warn',
      '@adaptavant/eds/prefer-eds-components': 'warn',
    },
  },
];

Suppress any rule on one line:

{/* eslint-disable-next-line @adaptavant/eds/prefer-eds-components */}
<button ref={hiddenSubmitRef} type="submit" hidden />

The plugin ships a CI mode (@adaptavant/eslint-plugin-eds/ci, exposed as the eds-eslint-ci bin) that:

• lints only the lines changed in a pull request, so pre existing violations never surface and a repo can adopt the check without a cleanup first. The one exception is a file that fails to parse: a syntax error invalidates line mapping for the whole file, so it is reported even if it predates the PR;
• posts the findings as a PR comment, collapsing its own earlier comments;
• fails the check when a changed file does not parse.

.ts, .tsx, .js and .jsx are all linted.

For the first release the CI run reports every rule as a warning, whatever severity the rule carries in recommended, so no rule violation can fail a PR. A file that does not parse is the one thing that still does, because a syntax error invalidates line mapping for the whole file. Rules will be promoted to blocking in a later release, once there is feedback on false positives in real consumer code.

Consume it through the shared eds-eslint-ci reusable workflow rather than running the bin directly:

name: EDS ESLint

on:
  pull_request:
    paths:
      - '**/*.ts'
      - '**/*.tsx'
      - '**/*.js'
      - '**/*.jsx'
      - '.github/workflows/eds-eslint.yml'

jobs:
  eds-eslint:
    uses: Adaptavant/aw-workflows/.github/workflows/eds-eslint-ci.yml@1
    with:
      version: 0.0.1 # pin an exact plugin version for reproducible runs
    secrets:
      PACKAGES_TOKEN: ${{ secrets.PACKAGES_TOKEN }}

See the workflow's own header for adoption details, including the fork pull request limitation.

Only inline eslint-disable comments are honoured in CI. The check runs a standalone config and ignores your repo's own ESLint setup, so config level off, overrides and ignorePatterns do not apply to it.

ESLint plugin rules documents each rule: what it reports, what it deliberately leaves alone, and the options it takes.