@silvermine/eslint-plugin-silvermine

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

Next, install @silvermine/eslint-plugin-silvermine:

$ npm install @silvermine/eslint-plugin-silvermine --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install @silvermine/eslint-plugin-silvermine globally.

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

• fluent-chaining
• call-indentation
• array-indentation
• no-multiple-inline-functions

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.