@goodlawyer/eslint-config v2.0.0

eslint-config-goodlawyer

Official Goodlawyer ESLint + Prettier Configurations

Release schedules

We maintain 2 release schedules. Each release schedule contains a different set of configurations.

Configs

ESLint

For each release schedule, we have 3 ESLint configs: (1 installation)

More specific configs all extend from a base config for consistency. Any stack-specific ruleset should go in their respective config files, and any general rulesets that should be shared across all specific configs can go in the base config.

Prettier

This package also includes a shared Prettier config, which can be used among any stack: | import path | file | description | | ----------------------------------- | ----------- | ------------------------------------------ | | @goodlawyer/eslint-config/prettier | prettier.config.cjs | Prettier configs |

npm install -D @goodlawyer/eslint-config

Install Peer Dependencies

npm install -D eslint prettier lint-staged husky

Add Prettier Config

https://prettier.io/docs/en/configuration.html#sharing-configurations

// Example using `package.json`
{
	...,
	"prettier": "@goodlawyer/eslint-config/prettier"
}

Create ESLint Config File

https://eslint.org/docs/developer-guide/shareable-configs#using-a-shareable-config

// Example using `.eslintrc.json` in a backend project root
{
	"extends": "@goodlawyer/eslint-config/backend"
}

Use @goodlawyer/eslint-config/frontend for frontend projects. For special-cases like NextJS, see Environments > NextJS.

Add Precommit Hook

Add a precommit hook to package.json to automatically lint* and format any files staged for commit

// package.json
"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "concurrent": false,
  "linters": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --quiet",
      "git add"
    ],
    "*.{ts,tsx,js,jsx}": [
      "prettier --write",
      "git add"
    ]
  }
}

*In projects that has many code-smells not fixable by linters, this can become problematic as you cannot push without fixing the lint errors. Remove linting but keep formatting if necessary.

Add Scripts

Add scripts for linting and formatting to package.json

// package.json
"scripts": {
  "lint": "eslint .",
  "format": "prettier --write \"**/*.{ts,tsx,js,jsx}\"",
  "format:check": "prettier --debug-check \"**/*.{ts,tsx,js,jsx}\""
}

Environments

NextJS

NextJS inludes their own ESLint plugin out of the box as of v11. To add this on top of the frontend rules, you must extend from the plugin directly:

https://nextjs.org/docs/basic-features/eslint#migrating-existing-config

// Example using `.eslintrc.json` in a frontend NextJS project root
{
	"extends": ["@goodlawyer/eslint-config/frontend", "plugin:@next/next/recommended"]
}

Also make sure that build output files are not linted or formatted, see Usage > Ignore Files

Format Code

If you've added Prettier to an existing project you will want to format all the code before making any further changes. This should also be done entirely within in it's own commit, excluding changes made by installation above. This is to prevent mixing commits that include actual code-changes and formatting changes.

Before formatting, it's a good idea to run a soft-check to verify the files that will be formatted. This mindful check can verify whether you're ignoring files that should be ignored, before going to CI (ie. tests, build outputs). See Ignore files

npm run format:check

To format an entire codebase, run

npm run format

Ignore files

There might be files that do shouldn't need linting & formatting, like test files or build outputs. You can add a .prettierignore at project root to do this:

// .prettierignore

/* Testing frameworks */
cypress

/* NextJS */
.next

If you're needing to do this often, consider adding an ignorePatterns config in one of our configs above.

https://eslint.org/docs/user-guide/configuring/ignoring-code#ignorepatterns-in-config-files

1. Update the version in package.json
2. Commit your changes with a detailed message of what changed
3. npm pack --dry-run to see what will be published
4. npm publish
5. (optional) Create a release on GitHub. Use the version as the tag and release name. For example for version 1.0.0 the tag and release name would be v1.0.0. Add the commit details to the release.

Rulesets (outdated)

Goodlawyer Engineering, MIT License