0.11.2
Lint open source repositories for common issues.
Repolinter requires Node.JS >= v10 to function properly. Once Node.JS is installed, you can install Repolinter using npm
:
npm install -g repolinter
Once installed, run the following to lint a directory:
repolinter lint <directory>
The above command will lint <directory>
with the local repolinter.json
ruleset or the default ruleset if none is found:
repolinter % repolinter lint . Target directory: <directory> Lint: ✔ license-file-exists: Found file (LICENSE) ✔ readme-file-exists: Found file (README.md) ✔ contributing-file-exists: Found file (CONTRIBUTING) ✔ code-of-conduct-file-exists: Found file (CODE-OF-CONDUCT) ✔ changelog-file-exists: Found file (CHANGELOG) ... repolinter % echo $? 0
Repolinter also supports linting a git repository using the --git
flag. With this flag enabled, the directory input will be interpreted as a git URL which Repolinter will automatically clone into a temporary directory.
repolinter lint -g https://github.com/todogroup/repolinter.git
The Repolinter CLI currently supports three output formatting modes:
You can switch formatters using the --format
flag. An example of using the JSON formatter:
repolinter % repolinter lint --format json . {"params":{"targetDir":"/Users/nkoontz/Documents/code/repolinter","filterPaths":[],...
An example of using the Markdown formatter:
repolinter % repolinter lint --format markdown .
# Repolinter Report
This Repolinter run generated the following results:
| ❗ Error | ❌ Fail | ⚠️ Warn | ✅ Pass | Ignored | Total |
|---|---|---|---|---|---|
| 0 | 0 | 0 | 15 | 10 | 25 |
...
Repolinter supports an allowed list of paths through the --allowPaths
option to prevent the accidental linting of build artifacts. These paths must still be contained in the target directory/repository.
repolinter lint --allowPaths ./a/path --allowPaths /another/path
By default Repolinter will automatically execute fixes as specified by the ruleset. If this is not desired functionality, you can disable this with the --dryRun
flag.
Similar to how eslint uses an eslintrc file to determine what validation processes will occur, Repolinter uses a JSON or YAML configuration file (referred to as a ruleset) to determine what checks should be run against a repository. Inside a ruleset, there are two main behaviors that can be configured:
These combined capabilities give you fine-grained control over the checks Repolinter runs.
Repolinter will pull its configuration from the following sources in order of priority:
--rulesetFile
or --rulesetUrl
repolint.json
, repolinter.json
, repolint.yaml
, or repolinter.yaml
file at the root of the project being lintedAny ruleset starts with the following base, shown in both JSON and YAML format:
{
"$schema": "https://raw.githubusercontent.com/todogroup/repolinter/master/rulesets/schema.json",
"version": 2,
"axioms": {},
"rules": {}
}
version: 2
axioms: {}
rules:
Where:
$schema
- points to the JSON schema for all Repolinter rulesets. This schema both validates the ruleset and makes the ruleset creation process a bit easier.version
- specifies the ruleset version Repolinter should expect. Currently there are two versions: omitted for legacy config (example) and 2
for all others. Use 2
unless you know what you're doing.axiom
- The axiom functionality, covered in Axioms.rules
- The actual ruleset, covered in Rules.Rules are objects of the following format:
"<rule-name>": {
"level": "error" | "warning" | "off",
"rule": {
"type": "<rule-type>",
"options": {
// <rule-options>
}
},
"where": ["condition=*"],
"fix": {
"type": "<fix-type>",
"options": {
// <fix-options>
}
},
"policyInfo": "...",
"policyUrl": "..."
}
<rule-name>:
level: error | warning | off
rule:
type: <rule-type>
options:
<rule-options>
where: [condition=*]
fix:
type: <fix-type>
options:
<fix-options>
policyInfo: >-
...
policyUrl: >-
...
rule
- The check to perform. Repolinter can perform any check listed under the rules documentation. Unlike eslint, Repolinter checks are designed to be reused and specialized: for example, the file-existence
check can be used in a README-file-exists
rule and a LICENSE-file-exists
rule in the same ruleset. This allows a user to write a very specific ruleset from configuring generic checks.level
- The error level to notify if the check fails. warning
will not change the exit code and off
will not run the check.where
- Conditionally enable or disable this rule based off of axioms. Strings in this array follow the format of <axiom>=<value>
, where value is either an axiom output or *
to simply test if the axiom is enabled. If this option is present, this rule will only run if all specified axiom outputs are present. The available axioms in Repolinter can be found in the axioms documentation.fix
(optional) - The action to perform if the check performed by rule
fails. Repolinter can perform any action listed under fixes documentation.policyInfo
, policyUrl
(optional) - Information used by the formatter to indicate why the check exists from a policy perspective. Note: policyInfo
will automatically have a period appended to it for formatting purposes.A minimal example of a rule that checks for the existence of a README
:
"readme-file-exists" : { "level": "error", "rule": { "type": "file-existence", "options": { "globsAny": ["README*"] } } }
readme-file-exists:
level: error
rule:
type: file-existence
options:
globsAny:
- README*
Checking that the README
matches a certain hash, and replacing it if not:
"readme-file-up-to-date" : { "level": "error", "rule": { "type": "file-hash", "options": { "globsAny": ["README*"], "algorithm": "sha256", "hash": "..." } }, "fix": { "type": "file-create", "options": { "file": "README.md", "replace": true, "text": { "url": "www.example.com/mytext.txt" } } }, "policyInfo": "Gotta keep that readme up to date", "policyUrl": "www.example.com/mycompany" }
readme-file-up-to-date:
level: error
rule:
type: file-hash
options:
globsAny:
- README*
algorithm: sha256
hash: "..."
fix:
type: file-create
options:
file: README.md
replace: true
text:
url: www.example.com/mytext.txt
policyInfo: Gotta keep that readme up to date
policyUrl: www.example.com/mycompany
"axioms": { "<axiom-id>": "<axiom-target>" }
axioms:
<axiom-id>: axiom-target
Each axiom is configured as a key value pair in the axioms
object, where <axiom-id>
specifies the program to run and <axiom-target>
specifies the target to be used in the where
conditional. The available axiom IDs can be found in the axiom documentation. It should be noted that some axioms require external packages to run.
An example configuration using an axiom to detect the packaging system for a project:
{
"$schema": "https://raw.githubusercontent.com/todogroup/repolinter/master/rulesets/schema.json",
"version": 2,
"axioms": {
"packagers": "package-type"
},
"rules": {
"this-only-runs-if-npm": {
"level": "error",
"where": ["package-type=npm"],
"rule": { /* ... */ }
}
}
}
version: 2
axioms:
packagers: package-type
rules:
this-only-runs-if-npm:
level: error
where: [package-type=npm]
rule:
...
Some axioms (ex. contributor-count
) output numerical values instead of strings. For these axioms, numerical comparisons (<
, >
, <=
, >=
) can be also be specified in the where
conditional. Note that if a numerical comparison is used for a non-numerical axiom, the comparison will always fail.
{
"axioms": {
"contributor-count": "contributors"
},
"rules": {
"my-rule": {
"where": ["contributors>6", "contributors<200"],
// ...
}
}
}
axioms:
contributor-count: contributors
rules:
my-rule:
where:
- contributors>6
- contributors<200
rule:
...
A ruleset can extend another ruleset, in which case the two files will be recursively merged. Extended rulesets can themselves extend additional rulesets up to 20 rulesets deep.
Extend a ruleset by including an "extends" top-level key which identifies a URL or file path:
{ "extends": "https://raw.githubusercontent.com/todogroup/repolinter/master/rulesets/default.json" "rules": { # disable CI check "integrates-with-ci": { "level": "off" } } }
extends: https://raw.githubusercontent.com/todogroup/repolinter/master/rulesets/default.json
rules:
# disable CI check
integrates-with-ci
level: off
...
Relative paths are resolved relative to the location used to access the extending file. For example, if repolinter is invoked as:
repolinter -u http://example.com/custom-rules.yaml
And that ruleset includes extends: "./default.yaml"
, the path will be resolved
relative to the original URL as http://example.com/default.yaml
. If instead
repolinter is invoked as:
repolinter -r /etc/repolinter/custom-rules.yaml
And that ruleset includes extends: "./default.yaml"
, the path will be resolved
relative to the original file path as /etc/repolinter/default.yaml
.
YAML and JSON rulesets can be extended from either format.
Repolinter also includes an extensible JavaScript API:
const repolinter = require('repolinter')
const result = await repolinter.lint('.')
This API allows the developer to have complete control over the configuration and formatting Repolinter should use. Documentation for this library can be found under API Documentation.
This project is licensed under the Apache 2.0 license.
Repolinter is broken down into 7 main components, each of which is contained in a subfolder:
Axioms are registered in axioms/axioms.js and in rulesets/schema.json. An axiom implementation consists of a module with the following interface:
async (fs: FileSystem) => Result
Where fs is a FileSystem
scoped to the current repository.
The contents of the result should be an array of targets where t.path
is a target that the axiom has determined is valid (ex. for language detecting axiom a possible result could be new Result('', [{ path: 'javascript' passed: true }, { path: 'typescript', passed: true}], true)
). If the axiom fails to execute, it should return a failing result with an error message included instead of throwing an error.
A rule consists of two parts: a JavaScript module, which determines the rule's functionality and a JSON schema, which validates the rule's configuration options in rulesets. Rules are registered in rules/rules.js and rulesets/schema.json. Rules are also documented under rules.md.
The configuration JSON schema determines how rule.options
should be validated for this rule. All JSON Schema tools supported by AJV all available, with a few important caveats:
<rule-name>-config.json
and be located under the rules
folder.object
.$id
field should be an absolute raw.githubusercontent.com URL to where the schema is hosted on GitHub (ex. https://raw.githubusercontent.com/todogroup/repolinter/master/rules/apache-notice-config.json). This allows IDEs such as VSCode to apply the schema via a URL.To get started, you can use the following template:
{
"$schema": "http://json-schema.org/draft-07/schema",
"$id": "https://raw.githubusercontent.com/todogroup/repolinter/master/rules/<rule-name>-config.json",
"type": "object",
"properties": {}
}
Due to limitations with JSON Schema, you also must register your rule configuration schema in rulesets/schema.json by adding the following item to the list under root.then.properties.rules.properties.rule.allOf
:
{ "if": { "properties": { "type": { "const": "<rule-name>" } } }, "then": { "properties": { "options": { "$ref": "../rules/<rule-name>-config.json" } } } }
A rule implementation consists of a module with the following interface:
async (fs: FileSystem, opts /* type determined by your JSON schema */) => Result
Where fs is a FileSystem
scoped to the current repository and opts
is the options provided by the ruleset.
A rule implementation is encouraged to use Result#targets
to show the individual files/patterns checked when processing the rule. Including filenames in Result#message
is discouraged as it makes formatting difficult. If a rule fails to execute, it should throw an error.
A fix, similar to a rule, consists of two parts: a JavaScript module, which determines the fix's functionality and a JSON schema, which validates the fix's configuration options in rulesets. Fixes are registered in fixes/fixes.js and rulesets/schema.json. Fixes are also documented under fixes.md.
Fix JSON schemas work identically to rule JSON schemas, with the only difference the respective names and paths.
To get started, you can use the following template:
{
"$schema": "http://json-schema.org/draft-07/schema",
"$id": "https://raw.githubusercontent.com/todogroup/repolinter/master/fixes/<fix-name>-config.json",
"type": "object",
"properties": {}
}
Similar as with rules, you must register the fix schema in rulesets/schema.json by adding the following item to the list under root.then.properties.rules.properties.fix.allOf
(note that this is a different list than the rule registration list):
{ "if": { "properties": { "type": { "const": "<fix-name>" } } }, "then": { "properties": { "options": { "$ref": "../rules/<fix-name>-config.json" } } } }
Unlike rules, a fix implementation consists of a module with the following interface:
async (fs: FileSystem, options /* Type determined by your JSON schema */, targets: string[], dryRun: boolean) => Result
Where fs is a FileSystem
scoped to the current repository, opts
is the options provided by the ruleset, targets
are filepaths which did not pass the rule associated with this fix, and dryRun
determines if the fix is allowed to make changes to the repository.
The fix implementation is encouraged to use Result#targets
to show the individual files/patterns changed. If the fix fails to execute, it should either return a failed result or throw an error.
Formatters are exported by index.js and manually called by the CLI. A formatter implementation consists of the following interface:
interface Formatter {
formatOutput(output: LintResult, dryRun: boolean): string
}
Formatters do not print to STDOUT
instead choosing to return the output as a string.
If needed, a formatter can accept extra configuration from the ruleset through the formatOptions
property, which will be directly passed through to LintResult#formatOptions
. These options are not typed and are formatter dependent.
Below is a complete list of rules that Repolinter can run, along with their configuration options.
apache-notice
directory-existence
file-contents
file-existence
file-hash
file-no-broken-links
file-not-contents
file-not-exists
file-starts-with
file-type-exclusion
git-grep-commits
git-grep-log
git-list-tree
git-working-tree
json-schema-passes
license-detectable-by-licensee
best-practices-badge-present
apache-notice
No inputs. Checks for the presense of a NOTICE
file in the root of the repository. This rule is equivalent to the following:
{
"type": "file-existence",
"options": {"globsAny": ["NOTICE*"]}
}
directory-existence
Checks the existence of a given directory.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAny |
Yes | string[] |
A list of globs to search for. This rule passes if at least one glob returns a directory. | |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
fail-message |
No | string |
"" |
The string to print if the directory does not exist, used to create human-readable error messages. |
file-contents
Checks if the contents of a file match a given regular expression.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
Yes | string[] |
A list of globs to get files for. This rule passes if all of the files returned by the globs match the supplied string, or if no files are returned. | |
content |
Yes | string |
The regular expression to check using String#search . This expression should not include the enclosing slashes and may need to be escaped to properly integrate with the JSON config (ex. ".+@.+\\..+" for an email address). |
|
nocase |
No | boolean |
false |
Set to true to make the globs case insensitive. This does not effect the case sensitivity of the regular expression. |
flags |
No | string |
"" |
The flags to use for the regular expression in content (ex. "i" for case insensitivity). |
human-readable-content |
No | string |
The regular expression in content |
The string to print instead of the regular expression when generating human-readable output. |
fail-on-non-existent |
No | boolean |
false |
Set to true to disable passing if no files are found from globsAll . |
file-existence
Checks the existence of a given file.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAny |
Yes | string[] |
A list of globs to search for. This rule passes if at least one glob returns a file. | |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
dirs |
No | boolean |
false |
Set to true to include directories in the search (equivalent to directory-exists ) |
fail-message |
No | string |
"" |
The string to print if the directory does not exist, used to create human-readable error messages. |
file-hash
Checks that a given file matches a provided hash.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAny |
Yes | string[] |
A list of globs to search for. This rule passes if at least one file found matches the provided hash, and fails if no files are found. | |
hash |
Yes | string |
The hash to check against. Unless a different algorithm is specified, this will be sha256. |
|
algorithm |
No | string |
sha256 |
The hash algorithm to use. Repolinter supports any algorithm supported by crypto.createHash |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
succeed-on-non-exist |
No | boolean |
false |
Set to true to enable passing if no files are found from globsAll . |
file-no-broken-links
Scans a set of markup files for broken links. Links are tested by first rendering the markup file to HTML using github-markup, then each <a>
tag in the HTML is extracted and tested using broken-link-checker--as a result, this rule only supports checking markup formats supported by github-markup. Absolute URLs are checked using a HTTP request, and relative URLs are checked by accessing the file specified.
github-markup and its dependencies must be installed and available in PATH
to use this rule.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
Yes | string[] |
A list of globs to search for. This rule passes if all of the markup files found do not contain broken links. | |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
succeed-on-non-exist |
No | boolean |
false |
Set to true to enable passing if no files are found from globsAll . |
pass-external-relative-links |
No | boolean |
false |
Set to true to allow relative URLs outside of the target directory. As there is no good way to check these URLs, they will automatically pass if this setting is true. |
file-not-contents
Checks none of a given list of files match a given regular expression.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
Yes | string[] |
A list of globs to get files for. This rule passes if none of the files returned by the globs match the supplied string, or if no files are returned. | |
content |
Yes | string |
The regular expression to check using String#search . This expression should not include the enclosing slashes and may need to be escaped to properly integrate with the JSON config (ex. ".+@.+\\..+" for an email address). |
|
nocase |
No | boolean |
false |
Set to true to make the globs case insensitive. This does not effect the case sensitivity of the regular expression. |
flags |
No | string |
"" |
The flags to use for the regular expression in content (ex. "i" for case insensitivity). |
human-readable-content |
No | string |
The regular expression in content |
The string to print instead of the regular expression when generating human-readable output. |
fail-on-non-existent |
No | boolean |
false |
Set to true to disable passing if no files are found from globsAll . |
file-not-exists
Checks that a file doesn't exist.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
Yes | string[] |
A list of globs to search for. This rule fails if at least one glob returns a file. | |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
dirs |
No | boolean |
false |
Set to true to include directories in the search. |
pass-message |
No | string |
"" |
The string to print if the file does not exist, used to create human-readable error messages. |
file-starts-with
Checks that the first lines of a file contain a set of regular expressions.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
Yes | string[] |
A list of globs to search for. This rule passes if the starting contents of all found files match all patterns, and fails if no files are found. | |
lineCount |
Yes | number |
The number of lines to scan into for each file. | |
patterns |
Yes | string[] |
The regular expressions to check using String#search . These expressions should not include the enclosing slashes and may need to be escaped to properly integrate with the JSON config (ex. ".+@.+\\..+" for an email address). |
|
flags |
No | string |
"" |
The flags to use for the regular expressions in patterns (ex. "i" for case insensitivity). |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search on the files. This will not effect the case sensitivity of patterns . |
succeed-on-non-exist |
No | boolean |
false |
Set to true to enable passing if no files are found from globsAll . |
skip-binary-files |
No | boolean |
false |
Set to true to exclude binary files from globsAll . |
skip-paths-matching |
No | { extensions?: string[], patterns?: string[], flags?: string } |
{} |
Use this option to exclude paths from globsAll , either by file extension or by regular expression. |
file-type-exclusion
Checks that no files exist of a certain filetype.
Input | Required | Type | Default | Description |
---|---|---|---|---|
type |
Yes | string[] |
A list of globs to search for. This rule passes if no files are found. |
git-grep-commits
Searches Git commits for configurable blacklisted words. These checks can be a bit time consuming, depending on the size of the Git history.
Input | Required | Type | Default | Description |
---|---|---|---|---|
denylist |
Yes | string[] |
A list of patterns to search for. | |
ignoreCase |
No | boolean |
false |
Set to true to make denylist case insensitive. |
git-grep-log
Searches Git commit messages for configurable blacklisted words. These checks can be a bit time consuming, depending on the size of the Git history.
Input | Required | Type | Default | Description |
---|---|---|---|---|
denylist |
Yes | string[] |
A list of patterns to search for. | |
ignoreCase |
No | boolean |
false |
Set to true to make denylist case insensitive. |
git-list-tree
Check for blacklisted filepaths in Git.
Input | Required | Type | Default | Description |
---|---|---|---|---|
denylist |
Yes | string[] |
A list of patterns to search against all paths in the git history. | |
ignoreCase |
No | boolean |
false |
Set to true to make denylist case insensitive. |
git-working-tree
Checks whether the directory is managed with Git.
Input | Required | Type | Default | Description |
---|---|---|---|---|
allowSubDir |
No | boolean |
Whether or not to search subdirectories for a git repository. |
json-schema-passes
Checks if a given file matches a provided JSON schema. This check is performed using AJV.
Input | Required | Type | Default | Description |
---|---|---|---|---|
glob |
Yes | string |
The file to check a schema against. If more than one file is found, the first match will be checked. | |
schema |
Yes | JSON Schema | The JSON schema to validate against, as a JSON object. | |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search. |
human-readable-message |
No | string |
The schema in schema |
The string to print instead of the schema when generating human-readable output. |
succeed-on-non-exist |
No | boolean |
false |
Set to true to enable passing if no files are found from glob . |
license-detectable-by-licensee
Fails if Licensee doesn't detect the repository's license. This rule takes no inputs, but requires licensee
in the path, see command line dependencies for details.
best-practices-badge-present
Check Best Practices Badge is present in README. Optionally check a certain badge level is accomplished.
Input | Required | Type | Default | Description |
---|---|---|---|---|
minPercentage |
No | integer |
null |
Minimum Tiered Percentage accomplished by project. passing=100 , silver=200 , gold=300 , set to 0 or null to disable check. |
Below is a complete list of fixes that Repolinter can run, along with their configuration options.
file-create
Creates a file. Optionally removes or replaces files that failed.
Input | Required | Type | Default | Description |
---|---|---|---|---|
file |
Yes | string |
The file to create. Path can be relative to the repository or absolute. | |
text |
Yes | string | { url: string } | { file: string } |
The text to create the file with. Specify an object with the url or file property to pull text from a URL or file. |
|
replace |
No | boolean |
false |
Set to true to remove all failing files, as indicated by the rule. |
file-modify
Modify a file that failed a rule.
Input | Required | Type | Default | Description |
---|---|---|---|---|
text |
Yes | string | { url: string } | { file: string } |
The text to create the file with. Specify an object with the url or file property to pull text from a URL or file. |
|
files |
No | string[] |
Failing files specified by the rule | A list of globs to modify files with. If this value is omitted, file-modify will instead target files that failed the rule. |
skip-paths-matching |
No | { extensions?: string[], patterns?: string[], flags?: string } |
{} |
Use this option to exclude paths from files , either by file extension or by regular expression. |
write_mode |
No | "prepend" | "append" |
"append" |
How file-modify should edit the file. |
newlines |
No | { begin?: number, end?: number } |
{ begin: 0, end: 0 } |
How many newlines should be added to the start or end of text . This property allows formatters to print text without these newlines, creating a better user experience. |
file-remove
Removes a file or files.
Input | Required | Type | Default | Description |
---|---|---|---|---|
globsAll |
No | string[] |
Failing files specified by the rule | The list of globs to remove files for. If this value is omitted, file-remove will instead target files that failed the rule. |
nocase |
No | boolean |
false |
Set to true to perform an case insensitive search with globsAll . |
Below is a complete list of axioms that Repolinter can check.
contributor-count
This axiom uses gitlog to count the number of contributors to the current git repository. Contributors are counted based on unique occurrences of an author name in the git log. This axiom is a numerical axiom, meaning numerical comparisons can be used.
An example of using this axiom:
{
"axioms": {
"contributor-count": "contributors"
},
"rules": {
"my-rule": {
"where": ["contributors>6", "contributors<200"],
// ...
}
}
}
licensee
This axiom uses licensee to detect the license used in the current repository. To use this axiom licensee must be installed in your PATH
or in the same directory as Repolinter.
This axiom will return a list of license identifiers associated with the current repository.
An example of using this axiom:
{
"axioms": {
"licensee": "license"
},
"rules": {
"my-rule": {
"where": ["license=Apache-2.0"],
// ...
}
}
}
linguist
This axiom uses GitHub's linguist to detect programming languages in the current repository. To use this axiom, linguist must be installed in the system PATH
or in the same directory as Repolinter. This axiom will return a lowercase list of programming languages from this list of supported languages.
An example of using this axiom:
{
"axioms": {
"linguist":" language"
},
"rules": {
"my-rule": {
"where": ["language=javascript"],
// ...
}
}
}
packagers
This axiom detects the projects packaging system by looking for project metadata files such as the package.json. The list of detectable packaging systems can be found in the axiom source.
This formatter outputs the LintResult CLI style, including colors on supported platforms.
✔ license-file-exists: found (LICENSE) ✔ readme-file-exists: found (README.md) ✔ contributing-file-exists: found (CONTRIBUTING) ✔ code-of-conduct-file-exists: found (CODE-OF-CONDUCT) ✔ changelog-file-exists: found (CHANGELOG) ✔ readme-references-license: File README.md contains license ✔ license-detectable-by-licensee: Licensee identified the license for project: Apache License 2.0 ✔ test-directory-exists: found (tests) ✔ integrates-with-ci: found (.travis.yml) ✔ source-license-headers-exist: The first 5 lines of 'index.js' contain all of the requested patterns. ... ✔ github-issue-template-exists: found (ISSUE_TEMPLATE) ✔ github-pull-request-template-exists: found (PULL_REQUEST_TEMPLATE) ✔ package-metadata-exists: found (Gemfile) ✔ package-metadata-exists: found (package.json)
Type: Formatter
This formatter outputs the raw JSON string of the LintResult object.
Type: Formatter
This formatter outputs a markdown document designed to created into a GitHub issue or similar.
# Repolinter Report
This Repolinter run generated the following results:
| ❗ Error | ❌ Fail | ⚠️ Warn | ✅ Pass | Ignored | Total |
|---|---|---|---|---|---|
| 0 | 0 | 0 | 15 | 10 | 25 |
...
You can also specify formatOptions.disclaimer to include a disclaimer at the top of the markdown document.
Type: Formatter
The same as defaultFormatter @type {Formatter}
An exposed function for the repolinter engine. Use this function to run repolinter on a specified directory targetDir. You can also optionally specify which paths to allowlist (filterPaths), whether or not to actually commit modifications (fixes), and a custom ruleset object to use. This function will not throw an error on failure, instead indicating that an error has ocurred in returned value.
(string)
The directory of the repository to lint.
(boolean?
= false
)
If true, repolinter will report suggested fixes, but will make no disk modifications.
Promise<LintResult>
:
An object representing the output of the linter
Checks a rule's list of axioms against a list of valid targets, and determines if the rule should run or not based on the following rules criteria:
Supported numerical axioms are >, <, >=, <=, and = Only
Array<string>
:
The list pf unsatisfied axioms, if any. Empty array indicates the rule should run.
Run all operations in a ruleset, including linting and fixing. Returns a list of objects with the output of the linter rules
(Array<RuleInfo>)
A ruleset (list of rules with information about each). This parameter can be generated from a config using parseConfig.
(FileSystem)
A filesystem object configured with filter paths and a target directory.
(boolean)
If true, repolinter will report suggested fixes, but will make no disk modifications.
Promise<Array<FormatResult>>
:
Objects indicating the result of the linter rules
Given an axiom configuration, determine the appropriate targets to run against (e.g. "target=javascript").
(Object)
A configuration conforming to the "axioms" section in schema.json
(FileSystem)
The filesystem to run axioms against
Promise<Object<string, Result>>
:
An object representing axiom name: axiom results. The array will be null if the axiom could not run.
Object representing the result of a rule or fix job.
(string?)
Message to display to console indications the output of the job. Does not need to contain the list of files checked.
(Array<ResultTarget>)
A list of paths that this rule/fix changed or checked
(boolean)
Whether or not the rule/fix succeeded
A class containing parsed information from a single "rule" entry in the configuration.
"off"
| "error"
| "warning"
), where: Array<string>?, ruleType: string, ruleConfig: Object, fixType: (string | undefined)?, fixConfig: (object | undefined)?, policyInfo: (string | undefined)?, policyUrl: (string | undefined)?)A class representing the information produces by a single rule/fix check. Do not use the constructor for this class, prefer the static factory functions instead.
Extends FormatResultBase
(RuleInfo)
Information about the rule
(string?)
Message from the engine indicating why the rule may have been excluded. must be null if lintRes is present.
(string)
The "status" (error, ignored, ok) code, based on static values in FormatResult
(Result?)
The linter rule output
(Result?)
The fixer rule output
Create a FormatResult for a rule that only contains output from a lint rule
(RuleInfo)
Information about the rule
(Result)
The result from the linter rule
FormatResult
:
A FormatResult object
Create a FormatResult for a rule that contains output from both a lint and fix job.
(RuleInfo)
Information about the rule
(Result)
The result from the lint rule
(Result)
The result from the fix rule
FormatResult
:
A FormatResult object
Utility filesystem class that scopes operations to a given set of directories and a CWD
(any
= '.'
)
(any
= []
)
Find the first file or directory matching a list of globs. Globs are searched from first to last. Returns the relative path of that file or directory, or undefined if none was found.
(boolean)
Whether or not to ignore case-sensitivity
Promise<(undefined | string)>
:
A path relative to this.targetDir, or undefined if no items were found
Find the first file matching a list of globs. Globs are searched from first to last. Returns the relative path of that file, or undefined if none was found.
(boolean)
Whether or not to ignore case-sensitivity
Promise<(undefined | string)>
:
A path relative to this.targetDir, or undefined if no items were found
Find all files matching a list of globs. Globs are searched from first to last. Returns the relative path of all files, or undefined if none was found. Automatically removes symlinks from results.
(boolean)
Whether or not to ignore case-sensitivity
Promise<Array<string>>
:
A list of paths relative to this.targetDir
Find all files or directories matching a list of globs. Globs are searched from first to last. Returns the relative path of all items, or undefined if none was found. Automatically removes symlinks from results.
(boolean?
= false
)
Whether or not to ignore case-sensitivity
Promise<Array<string>>
:
A list of paths relative to this.targetDir
Type: Object
(function (LintResult, boolean): string)
: A function to format the entire linter output.
Type: Object
(Object)
: The parameters to the lint function call, including the found/supplied ruleset object.
params.targetDir
string
The target directory repolinter was called with. May also be a git URL.
params.filterPaths
Array<string>
The filter paths repolinter was called with.
params.rulesetPath
string??
The path to the ruleset configuration repolinter was called with.
params.ruleset
Object
The deserialized ruleset that Repolinter ran.
(boolean)
: Whether or not all lint rules and fix rules succeeded. Will be false if an error occurred during linting.
(boolean)
: Whether or not an error occurred during the linting process (ex. the configuration failed validation).
(string?)
: A string indication error information, will be present if errored is true.
(Array<FormatResult>)
: The output of all the linter rules.
(Object?)
: Additional options to pass to the formatter, generated from the output or config.
Determine if provided string is an absolute URL. That is, if it is parseable and has a 'host' URL component.
(string)
string to test
boolean
:
true if the string is an absolute URL
Find a repolinter config file in the specified directory. This looks for files named repolint or repolinter with a file extension of .json, .yaml, or .yml in the specified directory or the nearest ancestor directory. If no file is found, the default configuration that ships with repolinter is returned.
(string?)
directory to search for config files in
string
:
absolute path of configuration file
Load a ruleset config from the specified location.
(string)
A URL or local file containing a repolinter config file
(array?
= []
)
List of config files already processed, used to prevent loops
Object
:
The loaded repolinter json config
Type: Object
Type: Object
(string)
: status of the rule execution, either FormatResult.OK, FormatResult.IGNORED, or FormatResult.ERROR
(string??)
: a message why the rule was ignored or failed, or undefined if the rule ran successfully
(Result??)
: the linter result object, or undefined if the rule was ignored
(Result??)
: the fix result object, or undefined if no fix was present or the rule was ignored
(RuleInfo)
: the rule metadata object
The default CLI formatter. Exported as defaultFormatter and resultFormatter.
Format a FormatResult object into a line of human-readable text.
(Result)
The result to format, must be valid
(string)
The name of the rule this result is from
(string)
The symbol to use if the result did not pass
(string
= logSymbols.success
)
The symbol to use if the result passed
string
:
The formatted string
(LintResult)
The linter output to format
(boolean)
Whether or not to generate in "report" format
string
:
The formatted output
A JSON formatter for machines. Exported as jsonFormatter.
(LintResult)
The linter output to format
(boolean)
(ignored)
string
:
The formatted output
A markdown formatter for Repolinter output, designed to be used with GH issues. Exported as markdownFormatter.
Format a FormatResult object into a line of human-readable text.
(FormatResult)
The result to format, must be valid
(string)
The symbol to use at the start of the log line (ex. ✅)
(boolean??)
Whether or not to say the fix is "suggested" instead of "applied".
string
:
The formatted string
(LintResult)
The linter output to format
(boolean??)
Whether or not to print fix "suggested" or "applied"
string
:
The formatted output
A github markdown header slugger, based on the following fork of github-slugger: https://github.com/Flet/github-slugger/tree/25cdb15768737d7c1e5218d06d34a772faaf5851 Parse a unicode string into a markdown anchor link using a GitHub-flavored algorithm.
(string)
The heading to parse.
string
:
The slug to use in URLs.