Create SVG badges summarizing your ESLint results
MIT License
(see also licenses for dev. deps.)
Create badges to reflect the number/types of failing or passing eslint rules.
npm i eslint-formatter-badger
eslint -f badger .
Or, to get use of full options, use the CLI interface.
The programmatic API.
badgerDefault(resultsArray, {rulesMeta: <object>}, options) => ""
This method is needed as the default so as to work when called by eslint -f
.
However, the named exports badger
or badgerEngine
are to be
preferred for regular progrmmatic usage (or use our CLI) as the
ESLint formatting API forces us to adhere to these limitations:
options
if this is called programmatically,eslint -f
eslintFormatterBadgerOptions
property of the current workingpackage.json
.For the structure of the resultsArray
, see https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-results-object
and for the structure of the messages within that object, see https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-message-object.
For the structure of the rulesMeta
object, see https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-data-argument.
For options
, see badger
below.
badger
badger({results, rulesMeta, ...options})
For the structure of the rulesMeta
object, see https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-data-argument.
Note that in programmatic usage (not eslint -f
), a meta Map
as passed
in by cli.getRules()
(and as used by our badgerEngine
) can be used in addition to the
structure detailed at https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-data-argument.
The other options are the same as those detailed in the CLI.
badgerEngine
badgerEngine(options)
This is what is used by the CLI. See the CLI for the available options.
However, as a programmatic API, a few more type options are possible:
textColor
may be an array as well as a comma-separated string.ruleMap
, an object may be provided in place of a stringes-file-traverse
When we do not wish to lint all of node_modules
nor do we need to lint
entire project dependencies, we can use es-file-traverse
to lint just
those files which are actually in use in our project.
It can be particularly useful to make badges advertising the degree to which we have looked out for weaknesses in the third-party code we are using.
(Although any ESLint-based linting still depends on good faith (i.e., it is possible for dependencies to work around checks), one can still perform useful audits of the dependencies of one's project to catch problems of importance, such as finding code which introduces vulnerabilities or which is intrusive in polluting with globals, etc. (These tend to be more of the type of problems which third parties may be more willing to fix, as they are not mere stylistic concerns.))
Here is an example of eslint-formatter-badger
used to build our own
third-party linting badge for es-file-traverse
:
eslint-formatter-badger --mainTemplate=\"ESLint 3rd party light audit (\\${ruleMapCount} rules)\" --filteredTypes intrusive,vulnerability --ruleMap .eslintRuleTypeMap.json --outputPath badges/eslint-3rdparty.svg --eslintCache --noEslintInlineConfig --noUseEslintIgnore --noUseEslintrc --eslintConfigPath .eslintrc-3rdparty.js `es-file-traverse --file ./bin/cli.js --node --cjs`
The particular arguments which may be of interest:
--mainTemplate
- We override the main badge content here to highlight notruleMap
ruleMapCount
), which we use to indicate the number of applicable--ruleMap
- Rather than relying on the default of meta.type
tono-eval
as belonging to a "vulnerability" type--filteredTypes
to show the rule type(s) of interest).--filteredTypes
- We choose the rule types of interest (in this case,--eslintCache
- Sets ESLint cache
, creating .eslintcache
. Will be--noEslintInlineConfig
- 3rd parties may disable rules you wish to check,--noUseEslintIgnore
- Don't apply our own .eslintignore
to the explicit--noUseEslintrc
- We don't want to check the normal hierarchy of .eslintrc.*
--eslintConfigPath
to indicate the rules we--eslintConfigPath
- Indicates the actual rules we want applied to third party--file
es-file-traverse
.es-file-traverse...
) - This./bin/cli.js
.ruleMap
's so can combine results (e.g.,"no-eval": "vulernable", "no-global-assign": "intrusive"
)spec
while allowing empty stringbadge-up
if external SVG allows; somocha-badge-reporter
)