@silvermine/eslint-plugin-silvermine
v2.5.0
Published
eslint plugins to support our JS Code Standards. See @silvermine/eslint-config-silvermine
Downloads
8,576
Readme
Silvermine ESLint Plugin
What?
Shareable ESLint plugins that are used by our shareable config rules. See eslint-config-silvermine for more details.
Why?
Because we need it. Whitespace errors are evil. As are the other hundreds of types of errors this protects us from.
Installation
You'll first need to install ESLint:
$ npm install eslint --save-dev
+ [email protected]
installed 9 packages and audited 955 packages in 5.833s
Next, install @silvermine/eslint-plugin-silvermine
:
$ npm install @silvermine/eslint-plugin-silvermine --save-dev
+ @silvermine/[email protected]
installed 1 package and audited 955 packages in 4.95s
Usage
Add silvermine
to the plugins section of your .eslintrc
configuration file. You can
omit the eslint-plugin-
prefix:
{
"plugins": [
"@silvermine/eslint-plugin-silvermine"
]
}
Then configure the rules you want to use under the rules section.
{
"rules": {
"@silvermine/silvermine/fluent-chaining": 2
}
}
Supported Rules
Note on Semantic Versioning
There are some unusual concepts with this repo that we have to deal with when versioning it. For example, this repo is the set of plugins that are required by our eslint config, but this repo is itself linted by our eslint config - a cyclical dependency. Also, what is a "breaking change" in this repo? Definitely a major change to our coding standards (e.g. changing how many spaces we use for indents, or changing to tabs) would be a major, breaking change because every code file would need to be changed. But there are many smaller changes that can be made (introducing a new rule that we've basically followed by convention, for example) that are not really breaking, but may require some minor codebase changes when you upgrade to the newer rule config. Even fixing a bug (a patch version) could require changes to your codebase if the rule implementation was not finding violations previously.
Thus, we've decided that on this particular repo we will not strictly follow semantic versioning. Instead, new rules can be added with a minor version bump. Something that's strictly a bug fix of an existing rule (not changing the principle of the rule) can be done in a patch version. Major versions will be reserved for massive, sweeping changes in rules - in other words, primarily big policy changes rather than simply technical changes.
License
This software is released under the MIT license. See the license file for more details.