Flint is a Git-integrated code formatter that lets each developer work in their preferred style locally while maintaining a consistent style remotely. By automatically applying “local” and “remote” formatting passes during pull and push operations, Flint prevents formatting noise in commits and code reviews.
Pushing code
Pulling code
To get started quickly, head over to this link.
As code artisans, we each have our own tastes: brace styles, indent sizes, maximum line lengths… Yet when collaborating, these personal choices can diverge, clutter pull requests, and slow down code reviews. Existing tools like Prettier enforce strict, uniform rules that are convenient but inflexible when you want to keep a personal touch.
Flint bridges that gap: you code in your local style, then Flint automaticaly reformats to match the remote conventions before syncing to the repository. The result? Less cognitive friction, cleaner diffs, and perhaps a more relaxed team.
Opinionated vs. Customizable
Prettier presents itself as an “opinionated” formatter, reducing configuration surface at the cost of granular control. If you encounter a style you don’t like, you have no choice but to disable Prettier or sprinkle // prettier-ignore comments everywhere.
Configuration Drift
You can also rely on ESLint for auto-formatting, but that often means knee-jerk tweaks to dozens of rules, adjusting configurations project by project, and constantly juggling divergent overrides. In the end, you waste a lot of time on micro-adjustments and live in constant confusion.
According to cognitive load theory, our working memory can handle only a limited number of “chunks”. Each time we switch formatting style-indentation, brace placement, line breaks- we incur extra load that distracts from our code’s logic and design. Flint offers a two-mode formatting approach:
Local: You code in your usual style without interruption.
Remote: Flint reformats according to team conventions just before syncing.
This seperation lets you stay focused on the problem at hand and maintain a stable mental model during code review.
Key features
Git Integration
Flint interposes itself in your git pull and git push commands, inserting formatting steps transparently. There’s nothing new to learn-just keep using git as you always do.
Configurable Linter
A simple flint.config.json file lists your linters, each with local and remote command settings.For example, you might run ESLint with one config locally and a stricter config remotely.
Invisible Commit
During certain operations, Flint creates a temporary commit to track the style transition. The diffs correspond only to the difference between, your previous commit in your style and the current code in your style.
Getting Started
1.Install Flint using the available package manager of your choice.
2.Run flint init at the root of your project. This creates a hidden directory and a base configuration file.
3.Edit flint.config.json to adjust your formatting options: define your “local” and “remote” commands, the file types to include, and any other rules for your workflow.
4.If you haven’t already, initialize a Git repository with git init, then add a remote with git remote add.
5.Continue your usual Git workflow: before each pull, Flint applies the “remote” formatting then syncs your changes; before each push, Flint preserves your local style and then applie the “remote” formatting just before sending.
This seamless integration lets you benefit from Flint without disrupting your habits or referencing any specific linting or package-management tools.
To get started quickly, head over to this link.
References & Further Reading
Anthony Fu, “Why I don’t use Prettier”
Artem Zakirullin, “Cognitive load is what matters”
SOCIAL SHARE CARD GENERATOR