Shareable ESLint config for Scratch
Find a file
Ray Schamp 463f664f96 fix(base): Update rules for scratch-vm
Adjustments to the rules made while linting scratch-vm

TODO-style comments now warn. Trailing commas are explicitly not allowed (previously assumed this

rule was in effect with eslint/recommended).
2016-10-23 18:11:30 -04:00
.gitignore Initial commit 2016-10-21 16:56:57 -04:00
.travis.yml build(release): Configure semantic release 2016-10-23 10:47:15 -04:00
es6.js Fix up rules after one pass of linting 2016-10-22 11:47:23 -04:00
index.js fix(base): Update rules for scratch-vm 2016-10-23 18:11:30 -04:00
node.js fix(node): Split Node rules out from base config 2016-10-23 18:08:20 -04:00
package.json build(babel-eslint): Update semver format to match eslint 2016-10-23 18:05:01 -04:00
react.js fix(react): Extend react rules from react/recommended 2016-10-22 17:48:03 -04:00
README.md chore(git): Use commitizen 2016-10-22 12:23:06 -04:00

Scratch ESLint config

eslint-config-scratch defines the eslint rules used for Scratch Javascript projects

Committing

This project uses semantic release to ensure version bumps follow semver so that projects using the config don't break unexpectedly.

In order to automatically determine the type of version bump necessary, semantic release expects commit messages to be formatted following conventional-changelog.

Use the commitizen CLI to make commits formatted in this way:

npm install -g commitizen
npm install

Now you're ready to make commits using git cz.

Breaking changes

If you're committing a change that makes the linter more strict, or will otherwise require changes to existing code, ensure your commit specifies a breaking change. This will cause a major version bump so downstream projects must choose to upgrade the config and will not break the build unexpectedly.