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).
Derive the service version from build metadata instead of a hardcoded literal
A version string typed into code matches the manifest only until the next bump, and nothing in lint, types, or tests catches the drift - so read it from the package metadata or the build environment.
Bad example
| 1 | app.use(requestLogger({ name: "news-pusher", version: "1.0.0" })); |
Explanation (EN)
The literal duplicates package.json. After the first release bump every log line reports a version that was never deployed, and incident triage cannot identify the build.
Objašnjenje (HR)
Literal duplicira package.json. Nakon prve promjene verzije svaka linija logа prijavljuje verziju koja nikad nije deployana i trijaza incidenta ne moze prepoznati build.
Good example
| 1 | app.use( |
| 2 | requestLogger({ |
| 3 | name: process.env.SERVICE_NAME ?? "news-pusher", |
| 4 | version: process.env.SERVICE_VERSION ?? process.env.npm_package_version, |
| 5 | }), |
| 6 | ); |
Explanation (EN)
The version comes from the single source that the release process already updates, so it cannot go stale.
Objašnjenje (HR)
Verzija dolazi iz jedinog izvora koji proces izdavanja vec azurira, pa ne moze zastarjeti.
Notes (EN)
The same applies to any identity field you attach to telemetry: service name, commit sha, build id. Read them, do not retype them.
Bilješke (HR)
Isto vrijedi za svako polje identiteta koje prilazes telemetriji: ime servisa, commit sha, id builda. Procitaj ih, nemoj ih prepisivati.