commitguard v1.2.0
Motivation
CommitGuard is inspired by large projects in which it becomes hard to enforce deprecation or framework changes. For example, when trying to transition a large codebase from one framework to another, it's not only enough to actively port old code to the new framework, it's also necessary to ensure that new code won't be added using the old framework.
To solve this problem, CommitGuard audit at the changes you stage to commit against its ruleset and either prevents the commit if certain rules are broken, or warns the user if the problem isn't critical but the contributor should be mindful about something.
Install
npm install [-g] commitguard [--save-dev]You can install Commitguard globally or locally. Once installed, simply add a call to commitguard (either through commitguard if installed globally, or using something like npx if installed locally) to your pre-commit script.
Usage
You can configure CommitGuard by having a .commitguardrc file at the root of your project (same depth as .git) that is of the format
{
"version": 1,
"rules": [
{
"identifier": <rule identifier>,
"items": [
{
"level": <rule level>,
"comment": <comment>,
"pattern": <glob pattern>
},
...
]
}
]
}Note: You can also generate a template RC file by using commitguard init or npx commitguard init.
Rule identifiers are rule types implemented in Commitguard. As of the latest release, the supported identifiers are:
| Identifier | Description |
|---|---|
import-filter | Applies your pattern against all of your staged changes' import statements, any matches will apply the rule. |
no-positive-diff | Applies your pattern to file names in your stages changes. Any match that has additions will apply the rule. |
quarantine | Applies your pattern to file names in your staged changes. If quarantined files are part of stages changes, the rule is applied. |
Rule levels are either error or warn. If a rule with level error is triggered, the commit is aborted, while a warn prints warnings to stdout but allows the commit to go through.
Comments can be attached to rules and will be printed below the rule report when triggered. They can be used to provide details on why a rule exists, or where more information can be found.
Patterns are standard glob patterns and are used alongside minimatch to apply the rules.
Contributing
This project welcomes external contributions. Please refer to the issue tracker for a place to start! Also feel free to submit a feature request if you feel that something is lacking.