Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Verify the installed dependency supports newly used options
Before relying on a new library option, component attribute or method, verify support in the dependency version actually resolved by the consumer. Include the required manifest and lockfile update, or state and enforce the release prerequisite before enabling the behavior.
Bad example
| 1 | { |
| 2 | "dependencies": { |
| 3 | "@example/result-widget": "^1.2.0" |
| 4 | } |
| 5 | } |
Explanation (EN)
In this synthetic integration, the consumer now sets owner-ids but the widget first supports that attribute in 1.4.0. Keeping the old range and a lockfile resolved to 1.2.0 leaves the new attribute ignored at runtime.
Objašnjenje (HR)
U ovom izmišljenom primjeru potrošač sada postavlja owner-ids, a widget podržava taj atribut tek od 1.4.0. Stari raspon i lockfile koji i dalje bira 1.2.0 znače da se novi atribut ignorira tijekom izvršavanja.
Good example
| 1 | { |
| 2 | "dependencies": { |
| 3 | "@example/result-widget": "^1.4.0" |
| 4 | } |
| 5 | } |
Explanation (EN)
Raise the lower bound to the first supporting release and regenerate the package manager lockfile to a compatible version. Verify that the real widget passes owner-ids into its request, rather than checking only that the attribute appears in markup.
Objašnjenje (HR)
Podigni donju granicu na prvo izdanje koje podržava atribut i obnovi lockfile na kompatibilnu verziju. Provjeri da stvarni widget prenosi owner-ids u zahtjev, a ne samo da se atribut pojavljuje u HTML-u.
Notes (EN)
Applies when a consumer starts using an option introduced by a separate package change. Check the implementation or release evidence, the dependency range and the resolved version in the lockfile. A merged upstream PR is not proof that the consuming build includes it. Unknown custom-element attributes or loosely typed options may be silently ignored even when compilation succeeds. Test the observable behavior through the actual dependency. When release and consumer changes are separate, identify the prerequisite and keep the new behavior gated or unreleased until it is satisfied. Align package-extension or peer-override selectors with the dependency versions they are intended to support. An exact-version extension can silently stop applying after a compatible lockfile update. Set the minimum version to the first required API, preserve the verified peer contract and test frozen strict-peer installs. Do not extend a workaround to releases whose metadata semantics are unknown.
Bilješke (HR)
Primijeni kada potrošač počne koristiti opciju uvedenu zasebnom promjenom paketa. Provjeri implementaciju ili dokaz izdanja, raspon ovisnosti i stvarno odabranu verziju u lockfileu. Spojen upstream PR nije dokaz da ga build potrošača sadrži. Nepoznati atributi custom elemenata ili slabo tipizirane opcije mogu biti tiho ignorirani iako kompilacija prolazi. Testiraj vidljivo ponašanje kroz stvarnu ovisnost. Kada izdanje paketa i potrošač izlaze zasebno, navedi preduvjet i zadrži novo ponašanje iza provjerene kontrole ili izvan produkcije dok se preduvjet ne ispuni.
Exceptions / Tradeoffs (EN)
No dependency bump is needed when the resolved implementation already supports the option, including a verified workspace package or backport. Feature detection with a correct fallback can support older versions deliberately. Remotely supplied components need deployment or asset-version verification instead of a package lockfile change. Avoid unrelated upgrades and preserve the project versioning policy.
Iznimke / Tradeoffi (HR)
Nadogradnja nije potrebna kada odabrana implementacija već podržava opciju, uključujući provjereni workspace paket ili backport. Provjera mogućnosti uz ispravan fallback može namjerno podržati starije verzije. Za udaljeno učitane komponente provjeri isporučenu implementaciju ili verziju resursa umjesto lockfilea. Izbjegavaj nepovezane nadogradnje i poštuj politiku verzioniranja projekta.