eslint-config-allthings

ESlint shareable config for Allthings style

Setup

yarn add -DE @allthings/eslint-config

Usage

Create an eslint.config.js at your project root.

React projects

import allthingsConfig from '@allthings/eslint-config'

export default [
  ...allthingsConfig,
  {
    languageOptions: {
      parserOptions: {
        project: './tsconfig.json',
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
]

Node.js projects

import allthingsNodeConfig from '@allthings/eslint-config/node'

export default [
  ...allthingsNodeConfig,
  {
    languageOptions: {
      parserOptions: {
        project: './tsconfig.json',
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
]

Functional-style Node.js projects

Opt-in strict-functional variant of the Node config. On top of everything in /node, it forbids let, classes, this, and all object/array mutation via eslint-plugin-functional, and re-enables unicorn/no-array-reverse + unicorn/no-array-sort for consistency. Existing codebases will see a lot of errors on first run — this is intentional and aligns with the functional-programming style.

import allthingsFunctionalConfig from '@allthings/eslint-config/functional'

export default [
  ...allthingsFunctionalConfig,
  {
    languageOptions: {
      parserOptions: {
        project: './tsconfig.json',
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
]

Using with ESLint 10

The config supports both ESLint 9 and ESLint 10 (peerDependencies.eslint: ">=9.33.0 <11"). Two things to know:

Yarn install will print peer-dep warnings for eslint-plugin-react and eslint-plugin-jsx-a11y on ESLint 10 — both plugins still cap their declared peer at ^9 but work correctly at runtime. The warnings are cosmetic; you can ignore them or silence via YN0086 log filter in .yarnrc.yml. They go away when upstream releases land (tracked in jsx-eslint/eslint-plugin-react#3977).

React version is hardcoded to '18.3' in index.js. If your project is on React 19, override it in your own config so version-specific rules behave correctly:

import allthingsConfig from '@allthings/eslint-config'

export default [
  ...allthingsConfig,
  {
    languageOptions: {
      parserOptions: {
        project: './tsconfig.json',
        tsconfigRootDir: import.meta.dirname,
      },
    },
    settings: { react: { version: '19.1' } },
  },
]

Do not set settings.react.version: 'detect' on ESLint 10 — it triggers a context.getFilename is not a function runtime crash in [email protected] (the very reason we hardcode a string default). The crash is fixed in PR #3972 but not yet released.

Development

Run yarn link in the project folder

Run yarn link @allthings/eslint-config in the project that you want to test it against

After you finish run in your project yarn unlink @allthings/eslint-config and then yarn install --force to restore the initial state of dependencies

If yarn link isn't enough and you need a real published artifact, see Development release below.

Testing the config

The config is protected by a two-layer pipeline that runs in CI on every push:

• yarn test:audit — static rule audit. Loads each config and verifies every enabled rule still resolves in its plugin (catches rules removed or renamed by a dependency bump). Reports any rules whose meta.deprecated is set so we can migrate before they disappear.
• yarn test:behavioral — fixture-based check. Lints test/fixtures/full/ against index.js and test/fixtures/node/ against node.js. Files under src/clean/ must lint with zero errors; files under src/violations/ must trigger the rule IDs declared in manifest.json.

yarn test runs both. The CI workflow exposes them as separate steps so a Renovate PR makes it clear which layer regressed.

When adding or modifying a rule that consumers rely on, add a fixture line that exercises it — either a clean usage in clean/ or a violation file with a manifest.json entry.

Production release

!! DO NOT npm version !!

The project uses semantic-release which automates the whole package release workflow including:

• determining the next version number
• generating the release notes and publishing the package

This repository is also configured to squash-merge (see here).
When you squash merge, GitHub takes the title of the PR for the squash-merge's commit subject.

By choosing a proper PR title e.g. feat: my new feature your merged PR will trigger a new release.
See semantic-releases docs for available prefixes.

Development release

1. Create or check out the target branch from the commit you want to release.

2. Push the branch to trigger the CI pipeline:

   git push --force origin HEAD:beta   # or alpha / next

   The pipeline will automatically run semantic-release, which detects the branch name, bumps the version with the appropriate pre-release tag, and publishes it to npm under the matching dist-tag. Check Actions page for the release logs.

3. Install the pre-release in another project:

   yarn add -E @allthings/eslint-config@beta   # or @alpha / @next

   or use exact release (check versions on npm):

   yarn add -E @allthings/[email protected]

4. Promote to stable – once the pre-release is validated, create a PR from your target branch and proceed with Production release section.