Prettier + ESLint + Husky + lint-staged + commitlint

#linting.md

My personal & professional linting setup. Run's Prettier as an ESLint rule via their ESLint plugin. Dynamic support for react or non-react applications depending on your project dependencies. Dynamic inclusion of Kent C Dodds' ESLint Jest config depending on your project dependencies.

Convenient opt-in configs for projects using Docker or Ethereum to avoid common false positives.

To understand more, see https://github.com/codfish/eslint-config-codfish.

To avoid having to manually setup everything and add all configuration/boilerplate code to your project, use cod-scripts instead. It was forked and extended from kcd-scripts (inspired by react-scripts).

Installation

You may be able to uninstall a number of top-level dependencies from your project but be careful.

npm uninstall @babel/core @babel/cli @babel/preset-env @babel/preset-react eslint eslint-config-codfish prettier husky lint-staged jest @commitlint/cli @commitlint/config-conventional markdownlint-cli
npm install --save-dev cod-scripts
npm install --save @babel/runtime

Usage

Full usage: https://github.com/codfish/cod-scripts#usage

• Delete configuration.

sh -c 'rm -f .babelrc* .eslintrc* .eslintignore .huskyrc* .lintstagedrc* .prettierrc* .prettierignore jest.config.js .commitlintrc* commitlint* .markdownlint*'

• Delete any configs from the package.json, i.e. jest.
• Update package.json with the following:

"eslintConfig": {
  "extends": [
    "./node_modules/cod-scripts/eslint.js"
  ]
},
"husky": {
  "hooks": {
    "pre-commit": "cod-scripts pre-commit",
    "commit-msg": "cod-scripts commitlint -E HUSKY_GIT_PARAMS"
  }
}

• Adding eslintConfig to package.json is not required in theory but helps your editor enforce your eslint configuration.
• If you're building a dapp, you can extend codfish/dapp as well to adjust some eslint rules that throw false positive errors.

"eslintConfig": {
  "extends": [
    "./node_modules/cod-scripts/eslint.js",
    "codfish/dapp"
  ]
},

• Add desired scripts to package.json

Source Configuration

• .eslintignore
• .eslintrc.js
• .prettierignore
• .prettierrc.js
• .commitlint.config.js

package.json

{
  "scripts": {
    "build": "cod-scripts build -d core",
    "build:watch": "npm run build -- --watch",
    "format": "cod-scripts format",
    "lint": "cod-scripts lint",
    "lint:commit": "cod-scripts commitlint",
    "test": "cod-scripts test",
    "validate": "cod-scripts validate"
  },
  "eslintConfig": {
    "extends": [
      "./node_modules/cod-scripts/eslint.js"
    ]
  },
  "husky": {
    "hooks": {
      "pre-commit": "cod-scripts pre-commit",
      "commit-msg": "cod-scripts commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "commitlint": {
    "extends": [
      "./node_modules/cod-scripts/commitlint"
    ],
    "rules": {
      "scope-case": [2, "always", "pascal-case"],
      "scope-enum": [2, "always", [
        "SomeComponent",
        "SomeOtherComponent"
      ]]
    }
  }
}

First of all, thanks for these scripts, love it!

Also, I added an extra install step: npm install -g markdownlint-cli
since this is a gist I could not send you a pull request, see my fork: https://gist.github.com/Joostvanderlaan/55bf4c941fcf9ce80a4c5fd54a6b9e2c

@Joostvanderlaan thanks so much! My plan was to add markdown lint to cod-scripts eventually so that it didn't have to be separate process to install and use that. I have not had a chance to do that though.

Lately though I've personally had second thoughts about using it at all. I'm still on the fence and working through these thoughts but markdownlint seems to be the least useful and most frustrating of the linting tools in this process. As much as I LOVE linting, we've already got prettier doing a lot of cleanup for us. In theory 90+% of the time it's really not critical to catch these linting errors in markdown. With markdown, if someone wants to use two h1 headers (#) or jump from h2's (##) to h4's (####), who cares as long as it looks nice when it's transformed.

Maybe if you're building docs from markdown or have an entire repo of markdown files you could argue it would be a useful tool to enforce certain things. Anyway, I'm still mulling it over but I'm thinking about removing markdownlint from my linting equation!

Thanks again for the shoutout, I'd be interested to hear your thoughts!

@codfish you're right, it's a bit frustrating to use it. As for the jump from h2 to h4, I get you, but there's more useful rules as well. For example I like things like https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md003---heading-style so I can have consistency in heading styles when working with a team. Makes the files more easy to read. Same for rules like https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md005---inconsistent-indentation-for-list-items-at-the-same-level

Note to self: Investigate https://github.com/remarkjs/remark