Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Isolate major build-tooling upgrades into their own dedicated PRs
Don't bump major versions of package managers, bundlers, or runtimes inside an unrelated feature PR; do tooling migrations fully and in isolation.
Bad example
| 1 | // A feature PR titled "Code-split the header" |
| 2 | // Files changed: Header.tsx, MobileHeader.tsx, DesktopHeader.tsx |
| 3 | // ...and also, bundled in: |
| 4 | // package.json |
| 5 | - "packageManager": "pnpm@10.23.0+sha512..." |
| 6 | + "packageManager": "pnpm@11.0.9+sha512..." // brand-new major, just released |
| 7 | // + half-applied v11 config (leftover v10 keys, monorepo-only settings copied in) |
Explanation (EN)
A risky, brand-new major upgrade of the package manager is hidden inside an unrelated feature PR and only partially applied. The new major's startup behavior and config changes become an invisible variable that can break deploys, and reviewers can't reason about the feature and the migration at once.
Objašnjenje (HR)
Rizicna nadogradnja na potpuno novu glavnu verziju package managera skrivena je unutar nepovezanog feature PR-a i primijenjena samo djelomicno. Novo ponasanje pri pokretanju i promjene konfiguracije postaju nevidljiva varijabla koja moze srusiti deploy, a recenzenti ne mogu istovremeno procijeniti i znacajku i migraciju.
Good example
| 1 | // Feature PR: only the header code-splitting changes. |
| 2 | // package.json keeps the proven, stable major: |
| 3 | "packageManager": "pnpm@10.23.0+sha512..." |
| 4 |
|
| 5 | // Separate, dedicated PR: "Upgrade pnpm 10 -> 11" |
| 6 | // - bumps to the new major |
| 7 | // - adopts ALL recommended conventions (devEngines.packageManager, |
| 8 | // official image, new config syntax) instead of a half-migration |
| 9 | // - small, reviewable, easy to roll back in isolation |
Explanation (EN)
The feature PR stays on the stable major so the feature can be judged on its own. The tooling upgrade lives in its own focused PR that commits to the new version's conventions fully, making it easy to review, verify, and revert without dragging unrelated work with it.
Objašnjenje (HR)
Feature PR ostaje na stabilnoj glavnoj verziji kako bi se znacajka mogla ocijeniti zasebno. Nadogradnja alata zivi u vlastitom fokusiranom PR-u koji u potpunosti usvaja konvencije nove verzije, sto olaksava recenziju, provjeru i povrat bez povlacenja nepovezanog posla.
Notes (EN)
Especially true for tools whose checks run on every CI job or container start, where a regression surfaces only at deploy time.
Bilješke (HR)
Posebno vrijedi za alate cije se provjere izvrsavaju pri svakom CI jobu ili pokretanju kontejnera, gdje se regresija pojavi tek u trenutku deploya.
Exceptions / Tradeoffs (EN)
Patch or minor bumps of tooling that don't change behavior are fine inline. Security-critical upgrades may need to ship urgently regardless of PR boundaries.
Iznimke / Tradeoffi (HR)
Patch ili minor nadogradnje alata koje ne mijenjaju ponasanje mogu ici inline. Sigurnosno kriticne nadogradnje mogu se morati objaviti hitno bez obzira na granice PR-a.