1 | # Scratch ESLint config
|
2 |
|
3 | [![Greenkeeper badge](https://badges.greenkeeper.io/LLK/eslint-config-scratch.svg)](https://greenkeeper.io/)
|
4 |
|
5 | #### eslint-config-scratch defines the eslint rules used for Scratch Javascript projects
|
6 |
|
7 | ## Installation
|
8 | Install the config along with its peer dependencies, eslint and babel-eslint.
|
9 | ```bash
|
10 | npm install -D eslint-config-scratch eslint@3 babel-eslint@7
|
11 | ```
|
12 |
|
13 | If you're using the React config, also install the dependency for that
|
14 | ```bash
|
15 | npm install -D eslint-plugin-react@6
|
16 | ```
|
17 |
|
18 | ## Usage
|
19 | The configuration is split up into several modules:
|
20 | * `scratch`: The base configuration. Always extend this.
|
21 | * `scratch/node`: Rules for node, e.g., server-side code, tests, and scripts
|
22 | * `scratch/es6`: Rules for ES6, for use when you're transpiling with webpack
|
23 | * `scratch/react`: Rules for React projects
|
24 |
|
25 | Usually web projects have a mix of node and web environment files. To lint both
|
26 | with the appropriate rules, set up a base `.eslintrc.js` with the rules for node
|
27 | and then override the node configuration in `src` (where web code usually lives).
|
28 | E.g., with a file structure like this:
|
29 | ```
|
30 | scratch-project
|
31 | - .eslintrc.js
|
32 | - package.json
|
33 | - src
|
34 | - .eslintrc.js
|
35 | - index.js
|
36 | ```
|
37 | Your config files should be set up like
|
38 | ```javascript
|
39 | // scratch-project/.eslintrc.js
|
40 | module.exports = {
|
41 | extends: ['scratch', 'scratch/es6', 'scratch/node']
|
42 | };
|
43 |
|
44 | // scratch-project/src/.eslintrc.js
|
45 | module.exports = {
|
46 | root: true,
|
47 | extends: ['scratch', 'scratch/es6', 'scratch/react'],
|
48 | env: {
|
49 | browser: true
|
50 | }
|
51 | };
|
52 | ```
|
53 | This will set up all the files in the project for linting as Node.js by default,
|
54 | except for those in `src/`, which will be linted as ES6 and React files.
|
55 |
|
56 | If you're linting React, also make sure your lint script lints `.jsx` files:
|
57 | ```json
|
58 | "scripts": {
|
59 | "lint": "eslint . --ext .js,.jsx"
|
60 | }
|
61 | ```
|
62 |
|
63 | ## Committing
|
64 | This project uses [semantic release](https://github.com/semantic-release/semantic-release)
|
65 | to ensure version bumps follow semver so that projects using the config don't
|
66 | break unexpectedly.
|
67 |
|
68 | In order to automatically determine the type of version bump necessary, semantic
|
69 | release expects commit messages to be formatted following
|
70 | [conventional-changelog](https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md).
|
71 | ```
|
72 | <type>(<scope>): <subject>
|
73 | <BLANK LINE>
|
74 | <body>
|
75 | <BLANK LINE>
|
76 | <footer>
|
77 | ```
|
78 |
|
79 | `subject` and `body` are your familiar commit subject and body. `footer` is
|
80 | where you would include `BREAKING CHANGE` and `ISSUES FIXED` sections if
|
81 | applicable.
|
82 |
|
83 | `type` is one of:
|
84 | * `fix`: A bug fix **Causes a patch release (0.0.x)**
|
85 | * `feat`: A new feature **Causes a minor release (0.x.0)**
|
86 | * `docs`: Documentation only changes
|
87 | * `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
|
88 | * `refactor`: A code change that neither fixes a bug nor adds a feature
|
89 | * `perf`: A code change that improves performance **May or may not cause a minor release. It's not clear.**
|
90 | * `test`: Adding missing tests or correcting existing tests
|
91 | * `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
|
92 | * `chore`: Other changes that don't modify src or test files
|
93 | * `revert`: Reverts a previous commit
|
94 |
|
95 | Use the [commitizen CLI](https://github.com/commitizen/cz-cli) to make commits
|
96 | formatted in this way:
|
97 |
|
98 | ```bash
|
99 | npm install -g commitizen
|
100 | npm install
|
101 | ```
|
102 |
|
103 | Now you're ready to make commits using `git cz`.
|
104 |
|
105 | ## Breaking changes
|
106 | If you're committing a change that makes the linter more strict, or will
|
107 | otherwise require changes to existing code, ensure your commit specifies a
|
108 | breaking change. In your commit body, prefix the changes with "BREAKING CHANGE: "
|
109 | This will cause a major version bump so downstream projects must choose to upgrade
|
110 | the config and will not break the build unexpectedly.
|