Awesome
<h1 align="center">Precise Commits</h1> <p align="center"> <a href="https://travis-ci.org/nrwl/precise-commits"><img src="https://img.shields.io/travis/nrwl/precise-commits.svg?style=flat-square" alt="Travis"/></a> <a href="https://github.com/nrwl/precise-commits/blob/master/LICENSE"><img src="https://img.shields.io/npm/l/precise-commits.svg?style=flat-square" alt="GitHub license" /></a> <a href="https://www.npmjs.com/package/precise-commits"><img src="https://img.shields.io/npm/v/precise-commits.svg?style=flat-square" alt="NPM Version" /></a> <a href="https://www.npmjs.com/package/precise-commits"><img src="https://img.shields.io/npm/dt/precise-commits.svg?style=flat-square" alt="NPM Downloads" /></a> <a href="http://commitizen.github.io/cz-cli/"><img src="https://img.shields.io/badge/commitizen-friendly-brightgreen.svg" alt="Commitizen friendly" /></a> <a href="https://github.com/semantic-release/semantic-release"><img src="https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg?style=flat-square" alt="semantic-release" /></a> </p> <br>Why precise-commits
?
🔎 It is simply the most exact and least disruptive way to add consistent code formatting (by Prettier) to an existing codebase.
✨ You only reformat the exact code you have modified anyway as part of your normal development!
Tool | Staged files | Existing commits | PR Build | Arbitrary commands | Precision |
---|---|---|---|---|---|
precise-commits | ✅ | ✅ | ✅ | ❌ | Individual character ranges |
lint-staged | ✅ | ❌ | ❌ | ✅ | Entire File |
pretty-quick | ✅ | ❌ | ❌ | ❌ | Entire File |
Background
Implementing a new code-style in an existing codebase can be really tricky.
Prettier is an amazing automated code formatting tool, but that does not mean that introducing it into an existing codebase is trivial.
Regardless of how consistent the existing code-style might be, introducing Prettier will result in larger diffs, which:
- Increases the complexity and review time burden of PRs on senior team members.
- Potentially increases the amount of time it takes to complete a PR in the first place.
- Can block concurrent work on the same codebase and/or result in nasty merge conflicts with outstanding feature branches.
Other tools, such as lint-staged
, made an excellent first step towards mitigating the scope of the impact of the points above, by only running linters and formatters on files which have changed.
This is great for small codebases, in which the authors do not mind much that they are polluting the git history of the files they are touching, but it is not enough.
In large and enterprise codebases (particularly those organized as monorepos), the git history of each file is really important.
If I make a change on line 10 of a 4000 line file, I shouldn't be forced to reformat all 4000s lines (thus making me the last git user to update all of them) as part of my PR.
I should just need to reformat line 10.
This is where precise-commits
comes in!
Our ideal end-goal...
-
All developers on our team develop using consistent, automated formatting as they write their code. e.g. Running an IDE-based plugin, such as "vscode-prettier" with "format on save" enabled.
-
Each time they commit, a precommit hook is triggered to ensure that the staged code is formatted consistently.
-
Each time a Pull Request opened on our remote repo, a build is triggered on a CI server, during which the formatting is checked to ensure that all the files touched for that PR were formatted consistently.
How precise-commits
helps us get there...
-
All developers on our team write their code as they always have.
-
Each time they commit, a precommit hook is triggered which will run
precise-commits
on the code and ensure that the exact code they already modified is formatted consistently. Any untouched existing code will not be mutated. -
Each time a Pull Request opened on our remote repo, a build is triggered on a CI server, during which
precise-commits
runs to ensure that all the committed lines of code for that PR was formatted consistently.
...and after enough time has passed, our codebase will be formatted consistently, despite us never having to disrupt our feature-building momentum!
<br>How it works
Through analyzing your staged files (or any files modified between two given commit SHAs) precise-commits
will work out exactly what lines and characters within those files have actually been changed or added.
It then uses this information to run Prettier in a very focused way, allowing it to only reformat what is relevant for your current work, and allowing you to keep your PRs small and explicit!
<br>Installation
precise-commits
expects prettier
to be available as a peerDependency
, so you will need to install this yourself as a devDependency
of your project.
npm install --save-dev prettier precise-commits
<br>
Usage
It is intended that you will run precise-commits
as a CLI, and it will automatically pick up on any of the standard Prettier configuration files you may have in your project, including .prettierignore
files.
1. Running it manually
- Add an npm script to your package.json, such as:
{
//...
"scripts": {
"precise-commits": "precise-commits"
}
//...
}
- Execute the npm script, e.g. for the one above run:
npm run precise-commits
2. "Precommit" Hook
The recommended way to run precise-commits
is as a "precommit" hook.
A great tool for setting up the hook is husky
. You can install and run it as follows:
npm install --save-dev husky
Update the "scripts"
section of your package.json
:
{
//...
"scripts": {
"precise-commits": "precise-commits",
"precommit": "npm run precise-commits"
}
//...
}
3. As part of a PR build
When running a build for your PR, you can run precise-commits
to ensure that the author's changes are all formatted consistently.
The key things you need to configure are:
- The
--check-only
flag forprecise-commits
so that it will error out if it finds any inconsistent formatting - The
--head
and--base
flags so thatprecise-commits
knows what commits it should consider when resolving modified files. Most CI servers will have environment variables you can use to resolve these.
For example, if your PR is building on Travis, your config might look like this:
.travis.yml
# ... Other config options here ...
install:
- yarn install
script:
- 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then precise-commits --whitelist="src/**/*.ts" --check-only --head=$TRAVIS_PULL_REQUEST_SHA --base=$(git merge-base HEAD $TRAVIS_BRANCH); fi'
- yarn test
- yarn e2e
# ... Other config options here ...
<br>
CLI Configuration Options
As was hinted at above, the precise-commits
CLI supports a few different configuration options:
--whitelist
: [String, Default:"*"
]- Whitelist is a glob pattern (the glob syntax from the glob module is used).
- It is used to inform what files are considered when resolving modified files (by default all are considered).
- Don't forget the quotes around the globs! The quotes make sure that
precise-commits
expands the globs rather than your shell.
--formatter
: [String, Default:"prettier"
]- Currently only prettier is supported
- If you are interested in adding support for a different formatter, all you need to do is provide an object which implements this interface.
--check-only
: [Boolean, Default:false
]- Only check the code formatting is consistent with the resolved config
--base
: [String, NO DEFAULT]- Base commit SHA to be used in conjunction with the
--head
flag
- Base commit SHA to be used in conjunction with the
--head
: [String, CONDITIONAL DEFAULT]- Later commit SHA (e.g. the
HEAD
of a PR branch) to be used in conjunction with the--base
flag - NOTE on conditional default: If no value is provided for
--head
, but a value is given for--base
, it will default to checking "HEAD"
- Later commit SHA (e.g. the