@biffud/eslint-config

Expertly implemented ESLint configurations for overengineered projects.

A shareable ESLint configuration for TypeScript projects that pressures everybody on your team to care a little bit too much about code quality.

Usage

npm install --save-dev @biffud/eslint-config eslint

// eslint.config.mjs
import biffud from '@biffud/eslint-config';

export default [...biffud];

TypeScript

This config set is written for TypeScript projects. Its TypeScript rules apply to .ts, .mts, .cts and .tsx files only. The core ESLint rules also reach any JavaScript files you lint, but a JavaScript-only project is not what this package is designed for.

Type information

This config set is type aware, and finds your types using typescript-eslint's project service. Every TypeScript file you lint must be covered by one of your tsconfigs, and your own config must not set parserOptions.project: typescript-eslint refuses to parse when both are set.

Rules

Every rule this config sets lives in src/configs/, split by concern, and those files are the whole source of truth — if a rule is not in there, this package does not set it. src/index.ts just composes them in order.

Rules carry options only where we override a rule's default. A rule that reads 'error' alone takes ESLint's defaults deliberately, so anything spelled out is a deviation — reading src/configs/ tells you exactly where this config differs from ESLint's own judgement, and the reason is written next to it.

Options are positional, so a default that precedes one we override stays: dropping it would move the option after it into the wrong slot.

Every rule ships with a pair of code samples pinning the behaviour we expect from it; see src/test/.

Versioning

This package deliberately does not follow semantic versioning since just about every rule change would be breaking.

Since adapting a well established standard feels like a terrible idea, it feels appropriate for us to do so. Given that, our three positions are being reassigned:

| Position | Meaning | | --------- | ------------------------------------------------------------- | | Major | The ESLint major version this package supports. Nothing else. | | Minor | Rule changes and any other breaking change. | | Patch | Everything else — non-breaking additions and fixes alike. |

Practical consequence for consumers: use ~10.2.0 if you want your lint results to stay put, since that admits patch releases only. Use ^10.2.0 only if you are prepared for rule changes to arrive on their own schedule.

Development

Requirements

• Node — see .node-version for the expected version

Setup

Install dependencies:

npm install

Common Commands

To type check, lint, and check formatting:

npm run lint

To automatically fix what can be fixed:

npm run format

To build the package to dist/:

npm run build

Commit messages

Commits follow Conventional Commits, and the type decides the next version, so it is worth getting right:

| Marker | Release | Use for | | ---------------------------------- | ------- | ------------------------------------------------------------- | | feat | Minor | A consumer who changed nothing could newly see a lint error | | fix | Patch | Everything else that should reach consumers | | ! or a BREAKING CHANGE: footer | Major | This package moved to a new ESLint major. Nothing else, ever. |

build, chore, ci, docs, refactor, style and test release nothing. A breaking change is marked with a ! after the type or a BREAKING CHANGE: footer; it is never a type of its own.

The type is metadata and is not part of the description, which gets the fifty characters to itself:

feat: Add the yoda rule and consume it here

CI checks what it can — those fifty characters, the absent full stop, a body wrapped at seventy-two, and a description that is not wholly lower-case. The rest is convention rather than enforcement: the capitalization, the imperative mood, and a body that explains the why. All of it comes from the seven rules of a great commit message.

To check this branch's commits before opening a pull request:

npm run lint:commit

Releases

Merging to main publishes. The version comes from the commit types rather than from package.json, so getting the type right is the whole job; see AGENTS.md for how a release is guarded.

License

AGPL-3.0