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).
Verify the framework doesn't already handle it before adding a workaround
Confirm a suspected framework/library limitation actually exists before writing compensating code, and comment the verified reason — frameworks often already handle the case.
Bad example
| 1 | // Assumed dynamic imports need an absolute base in our cross-origin deploy, |
| 2 | // so we override base for every build: |
| 3 | base: isBuild ? `${BASE_URL_PLACEHOLDER}/` : undefined, |
| 4 | // (No verification that dynamic import paths were actually broken.) |
Explanation (EN)
The workaround is justified by an unverified assumption. Dynamic-import URLs are already emitted relative by the bundler, so part of this logic may be solving a problem that doesn't exist, with a misleading comment to match.
Objašnjenje (HR)
Zaobilazno rjesenje opravdano je neprovjerenom pretpostavkom. Bundler vec emitira URL-ove dinamickih importa kao relativne, pa dio ove logike mozda rjesava problem koji ne postoji, uz pogresno objasnjenje uz njega.
Good example
| 1 | // Verified: dynamic-import paths are emitted relative and work as-is. |
| 2 | // The placeholder base is needed ONLY because emitted JS/CSS reference |
| 3 | // static assets (images) via an absolute URL that must be rewritten at |
| 4 | // container startup. See set-base-url.js. |
| 5 | base: isBuild ? `${BASE_URL_PLACEHOLDER}/` : undefined, |
Explanation (EN)
The author checked the actual build output, found dynamic imports were fine, and kept the override only for the case that genuinely needed it — with a comment stating the verified reason.
Objašnjenje (HR)
Autor je provjerio stvarni izlaz builda, ustanovio da su dinamicki importi u redu i zadrzao nadjacavanje samo za slucaj kojemu je stvarno trebalo, uz komentar koji navodi provjeren razlog.