@silvermine/eslint-plugin-silvermine
Advanced tools
eslint plugins to support our JS Code Standards. See @silvermine/eslint-config-silvermine
Shareable ESLint plugins that are used by our shareable config rules. See eslint-config-silvermine for more details.
Because we need it. Whitespace errors are evil. As are the other hundreds of types of errors this protects us from.
You'll first need to install ESLint:
$ npm install eslint --save-dev
+ eslint@8.16.0
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/eslint-plugin-silvermine@2.4.0
installed 1 package and audited 955 packages in 4.95s
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
}
}
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.
This software is released under the MIT license. See the license file for more details.
FAQs
eslint plugins to support our JS Code Standards. See @silvermine/eslint-config-silvermine
The npm package @silvermine/eslint-plugin-silvermine receives a total of 1,042 weekly downloads. As such, @silvermine/eslint-plugin-silvermine popularity was classified as popular.
We found that @silvermine/eslint-plugin-silvermine demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
PEP 770 proposes adding SBOM support to Python packages to improve transparency and catch hidden non-Python dependencies that security tools often miss.
Security News
Socket CEO Feross Aboukhadijeh discusses open source security challenges, including zero-day attacks and supply chain risks, on the Cyber Security Council podcast.
Security News
Research
Socket researchers uncover how threat actors weaponize Out-of-Band Application Security Testing (OAST) techniques across the npm, PyPI, and RubyGems ecosystems to exfiltrate sensitive data.