If your linter isn't constantly yelling at you, it isn't strict enough.
You can install eslint-config-intolerable-style-guide
using npm via
npm install -D eslint-config-intolerable-style-guide eslint
The config will install all the plugins and whatnot, but this relies on eslint's plugin system finding them in the top of the node_modules kinda by chance. They should be peer dependancies, but I reckon it'll be fine like this. Worst case scenario: you just install the plugins needed yourself.
If you look in the example-project
folder, it will have the files you need.
They are all optional except for .eslintrc.yml
. At a minimum, that will need to be:
extends:
- intolerable-style-guide
parserOptions:
project: ./tsconfig.json
root: true
The .eslintignore
file is a gitignore style file to tell the linter what folders not to look at.
The .prettierrc
and .prettierignore
files will tell your IDE how to do formatting if you use the prettier plugin for it. If you just want eslint to fix those, you can leave it out.
It is also recommended to manually add a linting script to your package.json
, which should look like this:
"scripts": {
...
"lint": "eslint ."
}
This will allow you to run:
npm run lint
You could also consider running lint-staged to add some githooks to check the code before commit.
"lint-staged": {
"*.ts": "eslint"
}
None. It is perfect.
The main ruleset is maintained in the index.js
file. Most rules are commented with their justification for existence, and why decisions have been made.
There is also a jest.js
for including in projects that have jest.
And last there is the prettier.json
file that includes the prettier config. These are the big 3 files that are used when importing this config. If you add any, be sure to put them in the package.json
files
setting, as this repo is published with a whitelist and you new file will not be included in the publish without it.
This repository does not get transpiled at all, so ensure the code you write is compatible with the versions of node you want to run on.
This repository follows the Conventional Commits pattern for commit messages.
When it comes time for a release you should be able to find a pull request on the github repo that is offering to bump the version and update the changelog. This will also tag the github repo.
If you don't want to use this bot (or it broke or something), then you can fall back to running the npm run release
command and it will do the same thing for you.
To publish to NPM you just need to push a tag to github and it will automatically run the workflow to do this. You could also just publish locally.