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

This package contains best practice configs and rules for linting, type-checking, formatting and publishing JavaScript and TypeScript code. Use them to kickstart you next awesome web project 🚀!

npm install @peerigon/configs

Also checkout the instructions for each respective config:

• ESLint
• Prettier
• TypeScript
• Semantic release

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 should follow the community standard. Our config is therefore based on Prettier's default config. Besides that it also:

• auto-sorts import statements
• formats JSDoc comments
• formats package.json
• formats and sorts CSS properties
• sorts Tailwind CSS class names

This makes git diffs smaller and reviewing them more focussed.

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

MIT