peerigonconfigs
Best practice configs for ESLint, Prettier, TypeScript & friends. By Peerigon.
Installation
npm install @peerigon/configs --save-dev
Also checkout the instructions for each respective config:
AI
Furthermore, this package also contains rules and instructions for AI coding agents that are based on the configurations.
If you want your AI coding agent to stick to our configs and coding principles, put this in your project-specific rules file (like CLAUDE.md, .cursor/rules.mdc, etc.):
**Important**: You **must** follow [these rules](./node_modules/@peerigon/configs/ai/rules.mdc) and its language-specific rules referenced in that file.
Philosophy
Linting, formatting and type-checking rules are always a balance between:
- ease of reading
- ease of refactoring
- ease of writing.
We think that:
- code is read more often than refactored
- and refactored more often than written from scratch.
Our configs have been designed with these assumptions in mind.
Formatting
Formatting should follow the community standard. Our config is therefore based on Prettier's default config. Besides that it also:
- sorts
importstatements - formats JSDoc comments
- formats and sorts
package.jsonfields - formats and sorts CSS properties
- sorts Tailwind CSS class names
This makes git diffs smaller and reviewing them more focussed.
Linting
Linting should mostly catch bugs in the control flow and prevent security issues. Furthermore, it should enforce a modern, idiomatic and consistent code style that is easy to read and to refactor.
However, it should not nit-pick on formatting or favor certain language features where other options are equally ok. Every rule must be legitimized by objective criteria. A simple “I find it easier to read” is not enough.
Our linting rules:
- are mostly based on recommended sets
- use type information to catch logic bugs
- highlight a11y problems
- are less strict in tests
Type-checking
Type-checking should be rather strict because it is the foundation for safe and sound refactorings. If type-checking is too loose, it may lull the developer into a false sense of security. It should also prevent out-of-bounds errors when accessing arrays or objects.
For highly dynamic code or incompatible types, local exceptions to type safety and escape hatches need to be possible.
License
MIT
Sponsors
