configs

Best practice configs for ESLint, Prettier, TypeScript & friends. By Peerigon.



Installation

``sh
npm install @peerigon/configs --save-dev
`

Also checkout the instructions for each respective config:

- ESLint
- Prettier
- TypeScript
- Semantic release
- VSCode

$3

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.):

`md
Important: You must follow these rules 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.

$3

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.

$3

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

$3

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.

Scripts

This package also contains useful scripts for general project setups:

- sync-node-version.js - Syncs the Node version from package.json (@types/node`) into existing version files so they stay in sync.

See Scripts for more details.

License

MIT

Sponsors