configs

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:

• ESLint
• Prettier
• TypeScript
• Semantic release
• VSCode

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 import statements
• formats JSDoc comments
• formats and sorts package.json fields
• 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