CI/CD and code standards · Build
Code standards checked before every commit and again in CI
Your team’s conventions become pre-commit and CI checks, with a separate set for each codebase. A US marketplace ran them across nineteen repositories.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackPre-commit hooks · CI · ESLint with custom rules
Proof2 case studies
The service in 4 parts
01 · Who it’s for
A team whose conventions hold only while someone has time for careful review. Often the team is about to add AI to how it writes code, and then code arrives faster than anyone can read it closely.
02 · What we’ve built
- Rules across the nineteen repositories of a US marketplace, among them a ban on the any type, no component longer than 200 lines, and a typed request and response on every API call. Both the pre-commit hook and CI check them.Case study 03 →
- Our cross-platform design system has about 2,450 lines of verification that fail the build. CI also runs a real build with each of Next, Vite and Metro, because one of the rules is only truly checked by next build.Case study 01 →
- A review of our design system found 188 issues and traced them to three root causes, all of which had passed typecheck, ESLint and the build. Two of the three are now checks of their own: a label without a role, and a prop declared in a contract that can’t be traced to an element.Blog post →
03 · How we work
01 · SEVERITY BY STAGEA rule warns in the editor and fails in the hook and in CI, so it shows up at every stage but blocks only where that is cheap.
02 · WHAT RUNS WHEREFormatting and lint run in the hook, because they are fast. Types and tests run in CI, because they are slow and definitive.
03 · PER CODEBASEOn the marketplace, the web app, the backend and the component library each had their own set of rules.
04 · Stack
Pre-commit hooksCIESLint with custom rulesTypeScriptpnpm workspaces
Proof
Where we’ve done this before
Case study 03 · Platforms~50%Rules across the nineteen repositories of a US marketplace, among them a ban on the any type, no component longer than 200 lines, and a typed request and response on every API call. Both the pre-commit hook and CI check them.Read the case study →Case study 01 · Platforms74 / 678Our cross-platform design system has about 2,450 lines of verification that fail the build. CI also runs a real build with each of Next, Vite and Metro, because one of the rules is only truly checked by next build.Read the case study →WritingThree kinds of design system bug that TypeScript and ESLint missA review of our design system found 188 issues and traced them to three root causes, all of which had passed typecheck, ESLint and the build. Two of the three are now checks of their own: a label without a role, and a prop declared in a contract that can’t be traced to an element.Read the post →
FAQ
Questions about this service
Because one set for a backend and a design system ends up too permissive to matter in one or strict enough that people bypass it in the other. Deciding which rules belong in which codebase is a judgment call.
It will if it is slow. People start bypassing a hook that takes thirty seconds within a week, so the hook only runs the fast checks.
On the marketplace, the 200-line limit on components. It makes you split a component as soon as it starts to sprawl, while splitting is still easy.
Yes. We add the rules to the hooks and CI you already run, one codebase at a time.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.