0.8.4 — lockfile, którego nie było

Repozytorium silnika nie miało `bun.lock`. Instancje miały, silnik nie — bo silnik nie jest wdrażany, tylko wciągany do instancji, więc wyglądało to na plik bez zastosowania.

Konsekwencja jest taka, że dwa klony tego samego commitu mogą zbudować dwa różne drzewa zależności. Nie hipotetycznie: dokładnie to położyło produkcję dzień wcześniej, gdy w drzewie znalazły się dwie kopie routera i strona zaczęła się renderować po stronie serwera, a wywalać przy hydracji.

Brak lockfile'a jest błędem tej samej klasy co brak przypięcia wersji w konfiguracji wdrożenia. Różnica polega wyłącznie na tym, że objawia się później i u kogoś innego — u tego, kto sklonuje repozytorium za trzy miesiące i dostanie zestaw pakietów, którego nikt nigdy nie testował.

Więc: `bun.lock` wchodzi do repozytorium silnika, a w `package.json` siadają `overrides` wymuszające pojedynczą kopię `@tanstack/react-router`. Overrides są zabezpieczeniem drugiego rzędu — lockfile i tak powinien wystarczyć, ale ten konkretny błąd kosztował białą stronę na produkcji i nie ma powodu polegać na jednym mechanizmie.

Przy okazji do konwencji pracy weszła linijka, która wygląda na drobiazg: `rm -f package-lock.json` przed każdym commitem. Narzędzia potrafią wygenerować plik blokady drugiego menedżera pakietów przy okazji zupełnie innego polecenia, a dwa lockfile'e w jednym repozytorium to znowu ta sama loteria, tylko dobrze udokumentowana.

Świeży klon ma się rodzić odporny. To jedyny stan, w którym wersja w repozytorium znaczy cokolwiek.