Developer tooling
small-rules
Strict tooling is fine when it explains itself and doesn't get in the way.
Figure
fig. 1 — A rule report should point to a decision, not just announce a problem.
Project note
Ninety lint rules, moved from ESLint to Oxlint. The helpful messages came along.
The problem
A lint rule is only useful when it catches something real. It must also say what’s wrong. It should give enough context to fix the issue without opening six tabs. small-rules takes the rules I wrote for ESLint and ports them to Oxlint’s faster plugin system.
The approach
The rules take strong stances on purpose. They cover bugs, code health, consistency, and footguns that are specific to a project. Each rule has to justify the interruption it causes. Docs and focused tests are part of the rule. They aren’t cleanup after release.
The work is also a practical test of Oxlint’s plugin APIs. This site uses the package itself. Tooling is easier to trust when its maintainer has to use the defaults too.
What it demonstrates
- Designing diagnostics that are specific enough to act on.
- Maintaining a large rule surface without turning it into one undifferentiated package.
- Moving an existing ecosystem of checks onto a faster runtime.
- Treating documentation and tests as part of the public API.