https://github.com/softwareventures/precise-commits

:sparkles: Painlessly apply Prettier by only formatting lines you have modified anyway!
https://github.com/softwareventures/precise-commits

Last synced: 7 months ago
JSON representation

:sparkles: Painlessly apply Prettier by only formatting lines you have modified anyway!

• Host: GitHub
• URL: https://github.com/softwareventures/precise-commits
• Owner: softwareventures
• License: mit
• Fork: true (nrwl/precise-commits)
• Created: 2020-11-28T20:46:58.000Z (about 5 years ago)
• Default Branch: main
• Last Pushed: 2025-07-10T18:34:20.000Z (7 months ago)
• Last Synced: 2025-07-11T00:59:08.283Z (7 months ago)
• Language: TypeScript
• Homepage: https://www.npmjs.com/package/@softwareventures/precise-commits
• Size: 5.55 MB
• Stars: 14
• Watchers: 1
• Forks: 1
• Open Issues: 12
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
Precise Commits


This is a fork of the original project, with bug fixes and support for Windows

line endings.




# Why `precise-commits`?

🔎 It is simply **the most exact and least disruptive way** to add consistent

code formatting (by [Prettier](https://prettier.io)) 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](https://prettier.io) 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](https://prettier.io) will result in larger diffs, which:

1. Increases the complexity and review time burden of PRs on senior team

   members.

2. Potentially increases the amount of time it takes to complete a PR in the

   first place.

3. 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...

1. 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.

2. Each time they commit, a precommit hook is triggered to _ensure_ that the

   staged code is formatted consistently.

3. 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...

1. All developers on our team write their code as they always have.

2. 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.

3. 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!**




# 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](https://prettier.io) 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!




# 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.

```sh

npm install --save-dev prettier @softwareventures/precise-commits

```




# 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](https://prettier.io/docs/en/configuration) you

may have in your project, including

[`.prettierignore`](https://prettier.io/docs/en/ignore#ignoring-files) files.

## 1. Running it manually

1. Add an npm script to your package.json, such as:

```js

{

  //...

  "scripts": {

    "precise-commits": "precise-commits"

  }

  //...

}

```

2. Execute the npm script, e.g. for the one above run:

```sh

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`](https://github.com/typicode/husky). You can install and run it as

follows:

```sh

npm install --save-dev husky

```

Update the `"scripts"` section of your `package.json`:

```js

{

  //...

  "scripts": {

    "prepare": "husky install",

    "pre-commit": "npm run precise-commits"

  }

  //...

}

```

and create a `.husky/pre-commit` script:

```sh

#!/bin/sh

. "$(dirname "$0")/_/husky.sh"

npm run pre-commit

```

If you use yarn, you might want to add a workaround for the benefit of Windows

users, see https://typicode.github.io/husky/#/?id=yarn-on-windows

## 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:

1. The `--check-only` flag for `precise-commits` so that it will error out if it

   finds any inconsistent formatting

2. The `--head` and `--base` flags so that `precise-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](https://travis-ci.com/), your

config might look like this:

**.travis.yml**

```yaml

# ... 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 ...

```




# 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](https://github.com/isaacs/node-glob/blob/master/README.md#glob-primer)).

    - 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](https://github.com/nrwl/precise-commits/blob/master/src/precise-formatter.ts).




- `--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




- `--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"