Prettier + ESLint + Husky + lint-staged + commitlint

#linting.md

My personal & professional linting setup. Extends airbnb's ESLint config first, then Prettier. 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. Ultimate goal is maximize code linting coverage, leveraging the power of Prettier while deferring to Airbnb's style guide AS MUCH as possible without breaking anything. 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.

Installation

npm install --save-dev --save-exact prettier
npm install --save-dev husky lint-staged @commitlint/cli @commitlint/config-conventional markdownlint-cli
npx install-peerdeps --dev eslint-config-codfish

Usage

module.exports = {
  extends: ['codfish'],
  root: true,
};

.commitlintrc.js

module.exports = {
  extends: ['@commitlint/config-conventional'],  
  'scope-enum': [2, 'always', [
      // only allow scopes listed here
  ]],
  // https://conventional-changelog.github.io/commitlint/#/reference-rules?id=scope-case
  'scope-case': [2, 'always', 'pascal-case'],
};

.eslintignore

package.json
package-lock.json
node_modules
build
dist
public
serviceWorker.js
!.*.js

.eslintrc.js

module.exports = {
  extends: ['codfish'],
  root: true,
};

.huskyrc.js

module.exports = {
  hooks: {
    'pre-commit': 'lint-staged',
    'commit-msg': 'commitlint -E HUSKY_GIT_PARAMS'
  },
};

.lintstagedrc.js

module.exports = {
  '*.{json,css,scss,html}': ['prettier --write', 'git add'],
  '*.md': ['prettier --write', 'markdownlint', 'git add'],
  '*.js': ['eslint --fix', 'git add'],
};

.markdownlint.json

{
  "default": true,
  "line-length": {
    "line_length": 100,
    "code_blocks": false,
    "tables": false
  }
}

.prettierignore

package.json
package-lock.json
node_modules
build
dist
public
serviceWorker.js
!.*.js

.prettierrc.js

// override to defer to airbnb style guide. One source of truth!
module.exports = {
  singleQuote: true,
  trailingComma: 'all',
  printWidth: 100,
  proseWrap: 'always',
};

.travis.yml

sudo: false

language: node_js

node_js: '8'

cache:
  directories:
    - ~/.npm

install: npm install

script:
  - npm run lint:commit:ci
  - npm run lint:md
  - npm run lint

after_success:
  - npx -p semantic-release@7 -c "semantic-release pre && npm publish && semantic-release post"

branches:
  only: master
  

package.json

{
  "scripts": {
    "fix": "npm run format && npm run lint -- --fix",
    "format": "prettier --write \"**/*.{json,css,scss,md,html}\"",
    "lint": "eslint .",
    "lint:commit:ci": "commitlint-travis",
    "lint:md": "markdownlint -i node_modules ."
  }
}

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