Developer tooling / TypeScript
small-rules
Strict tooling earns its place when it explains itself and stays out of the way.
- Role
- Creator and maintainer
- Language
- TypeScript
- Focus
- Oxlint · linting · developer experience
The problem
A lint rule is only useful when it catches something real, reports it precisely, and offers enough context to fix the problem without opening six tabs. small-rules collects rules I had previously written for ESLint and ports them to Oxlint’s faster plugin system.
The approach
The collection is intentionally opinionated. Rules cover correctness, maintainability, consistency, and project-specific footguns, but each one has to justify the interruption it creates. Documentation and focused tests are part of the rule–not cleanup after the implementation.
The work also serves as a practical test of Oxlint’s plugin APIs. This site consumes the package itself, because tooling is easier to trust when its maintainer has to live with the defaults.
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.