@jstnmcbrd/eslint-config

About

A simple ESLint configuration for JavaScript, TypeScript, and React projects.

Uses @eslint/js, @stylistic/eslint-plugin, typescript-eslint, eslint-plugin-react, and eslint-plugin-react-hooks configurations.

Written in TypeScript and transpiles to JavaScript (ESM).

Introduction

I noticed I was duplicating much of the ESLint configuration between my projects, and synchronizing changes was annoying. So I have extracted the configuration into a new package to use anywhere.

You are welcome to use this configuration, but it is primarily designed for my personal use. I cannot promise to support your use case. However, I do plan to follow semantic versioning for handling breaking changes.

Usage

You must also install eslint to use this package.

npm install --save-dev eslint @jstnmcbrd/eslint-config

Add a script in your package.json for linting.

{
	"scripts": {
		"lint": "eslint ."
	}
}

Add a eslint.config.js file and import the configuration as follows.

import eslintConfig from '@jstnmcbrd/eslint-config';
export default eslintConfig();

React

import eslintConfig from '@jstnmcbrd/eslint-config';
export default eslintConfig({ react: true });

TypeScript

import eslintConfig from '@jstnmcbrd/eslint-config';
export default eslintConfig({ typescript: true });

This configuration assumes you have a typescript-eslint setup with a tsconfig.eslint.json file, as recommended by the documentation (see there for more details).

A good example can be found in this repository (tsconfig.eslint.json).

React + TypeScript

import eslintConfig from '@jstnmcbrd/eslint-config';
export default eslintConfig({ react: true, typescript: true });

Design

Flat Config

• Uses the new ESLint flat config
• No support for the legacy config, so consider upgrading!
• ESLint v9 is not supported yet

ECMAScript

• Transpiled by TypeScript to ECMAScript with ES modules
• No support for CommonJS, so consider upgrading!
• This means you cannot import the package from a node project that is not using "type":"module"

Simplicity

• Uses as few plugins as possible
• Uses plugins that are as official as possible, and avoids more esoteric/niche plugins
• Stays as close to recommended defaults as possible, with a few noteable exceptions
  • Tabs instead of spaces
  • Semicolons

No Prettier

• Does not use Prettier
  • It's good to be standardized and opinionated, but I find Prettier to be inflexible to the point of dogmatism. I created this package to enforce my own dogmatic opinions instead.
  • There's an interesting debate between the purposes of formatters and linters. Strict formatters often erase context encoded in code style, so flexibility can be useful for retaining the intent of the programmer.
  • For another perspective, see Anthony Fu's blog post on the subject.

Semantic versioning

This project aspires to abide by semantic versioning. However, given the interesting nature of updating code quality rules, it is not always clear what constitutes a "breaking" change. ESLint has a section on the subject in their README.

When I update a rule in a way that could cause a few harmless lint errors, I will try to always bump a minor version. If I update many rules, fundamentally change a rule, or change the configuration API, I will bump a major version.

Keep-a-changelog

This project abides by keep-a-changelog.

However, instead of a separate CHANGELOG.md file, see the description of releases on GitHub.