https://github.com/peerigon/configs
Best practice configs for ESLint, Prettier, TypeScript & friends. By Peerigon.
https://github.com/peerigon/configs
Last synced: 9 days ago
JSON representation
Best practice configs for ESLint, Prettier, TypeScript & friends. By Peerigon.
- Host: GitHub
- URL: https://github.com/peerigon/configs
- Owner: peerigon
- License: mit
- Created: 2024-10-10T15:51:49.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2026-06-24T11:34:57.000Z (12 days ago)
- Last Synced: 2026-06-24T13:20:58.751Z (11 days ago)
- Language: JavaScript
- Homepage:
- Size: 2.14 MB
- Stars: 4
- Watchers: 11
- Forks: 0
- Open Issues: 22
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Agents: AGENTS.md
Awesome Lists containing this project
README
# configs
**Best practice configs for [ESLint](https://eslint.org/), [Prettier](https://prettier.io/), [TypeScript](https://www.typescriptlang.org/) & friends. By [Peerigon](https://www.peerigon.com/).**
[](https://www.npmjs.com/package/@peerigon/configs)
[](https://jsr.io/@peerigon/configs)
[](https://github.com/semantic-release/semantic-release)
[](https://www.npmjs.com/package/@peerigon/configs)
[](./LICENSE)
## Installation
```sh
npm install @peerigon/configs --save-dev
```
This package requires Node.js 22 or newer.
Also checkout the instructions for each respective config:
- [ESLint](/eslint/README.md)
- [Prettier](/prettier/README.md)
- [TypeScript](/typescript/README.md)
- [Semantic release](/semantic-release/README.md)
- [VSCode](/.vscode/README.md)
### AI
Furthermore, this package also contains [rules and instructions for AI coding agents](./ai/README.md) 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.):
```md
**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
[
](https://peerigon.com)