ChristinaMcKibbe: Created page with "Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte..."

2026-08-21T17:27:20Z

Created page with "Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte..."

New page

Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte je do lokálního úložiště. Tím získáte přehled, která verze čeho je v sestavení použita. Další pastí je verzování samotného kódu podle data, nikoliv podle sémantické verze. Pokud přidáváte nové funkce, ale zároveň měníte staré, zvyšte major verzi. Pokud jen opravujete chyby, zvyšte minor verzi. Pokud měníte jen interní detaily, zvyšte patch. Toto pravidlo musí být napsané v dokumentaci projektu a každý člen týmu ho musí dodržovat. Bez toho se rychle stane, že dvě verze knihovny mají stejné číslo, ale různé chování, což je nejhorší možný scénář. Při práci na více feature větvích se snadno ztratí přehled o tom, která změna patří kam. Základním pravidlem je oddělit každou funkci do vlastní větve a držet ji co nejkratší dobu. Čím déle větev žije, tím větší je riziko konfliktů při merge a tím těžší je ji nakonec začlenit. Ideální je, když větev existuje maximálně pár dní a obsahuje jen jeden logický celek – jednu funkci, jedno vylepšení, jeden bugfix. Jak se vrátit zpět a nespálit se Nejčastější chybou začátečníků je panika, když něco rozbijí. Git vám umožní vrátit se k libovolnému předchozímu stavu. Pokud chcete zrušit změny v souborech, které ještě nejsou ve staging area, použijte git checkout -- . (nebo konkrétní soubor). Pokud jste už provedli git add, ale commit ještě ne, můžete příkazem git reset soubory ze staging area odebrat. Pokud jste udělali commit a chcete se vrátit o krok zpět, použijte git reset --soft HEAD~1, což zruší poslední commit, ale ponechá změny připravené k novému commitu. Prakticky doporučuji zavést automatizovaný skript, který ověří konzistenci verzí mezi všemi soubory projektu. Tento skript spusťte jako součást CI, tedy před každým nasazením. Měl by kontrolovat, že deklarované verze odpovídají skutečně použitým a že žádný modul neodkazuje na neexistující číslo. Dále nastavte pravidlo, že každá změna závislosti musí projít code review a musí být zapsána do changelogu. Tím se vyhnete situaci, kdy někdo tiše povýší knihovnu a až po měsíci se objeví problém v produkci. První praktický krok je instalace Dockeru. Na Linuxu využijete balíčkovací nástroj systému, na Windows a macOS stáhnete Docker Desktop. Po instalaci ověřte funkčnost příkazem docker --version a pak spusťte první kontejner: docker run hello-world. Tento miniaturní obraz vypíše zprávu a skončí. Všimněte si, že příkaz nejdřív obraz stáhne z registru a teprve potom spustí. To je normální chování – Docker pracuje s lokální cache, ale pokud obraz nemá, automaticky ho získá. Ladění JavaScriptu v prohlížeči je každodenní chlebíček každého frontend vývojáře. Přestože se to může zdát jako triviální záležitost, správné používání nástrojů pro vývojáře vám ušetří hodiny hledání chyb. Moderní prohlížeče nabízejí nepřeberné množství funkcí, které přesahují pouhé vypisování hodnot do konzole. Pokud se naučíte efektivně využívat breakpointy, watch expressions a další pokročilé nástroje, stanete se výrazně produktivnější. Pokročilé techniky, které vám ušetří čas Kromě klasických breakpointů vyzkoušejte podmíněné breakpointy – stačí kliknout pravým tlačítkem na číslo řádku a zvolit možnost přidat podmínku. Breakpoint se pak aktivuje pouze tehdy, když je splněna vámi zadaná podmínka, například když proměnná dosáhne určité hodnoty. To je neocenitelné při ladění cyklů nebo častých funkcí. Dalším užitečným nástrojem je watch expression – v panelu Watch si můžete přidat libovolný výraz, jehož hodnota se průběžně aktualizuje při každém kroku. Tím sledujete klíčové hodnoty bez nutnosti vypisovat je do konzole. Při práci na více feature větvích také vždy synchronizujte svůj lokální repozitář s originem, ale ne jen jednou na začátku. Průběžně si stahujte změny z mainu a rebasujte svou větev. Můžete si nastavit automatický fetch, ale raději si na to udělejte zvyk. Klíčem je, aby vaše větev nebyla nikdy příliš vzdálená od mainu. Pokud na ní pracujete déle než týden, zvažte, zda nemá smysl rozdělit ji na menší části, které lze dílčím způsobem začlenit. Na závěr si osvojte práci s konzolí. Kromě běžného console.log, console.warn a console.error využijte také console.table pro zobrazení polí a objektů v přehledné tabulce, což je mnohem čitelnější než dlouhý výpis. Pomocí console.time a console.timeEnd změříte dobu provádění úseku kódu, což je užitečné při hledání výkonnostních problémů. Nezapomínejte ani na možnost kopírovat objekt z konzole do schránky pomocí příkazu copy(), který se hodí při testování nebo posílání dat kolegům. Tyto zdánlivé drobnosti výrazně urychlí vaše každodenní ladění a pomohou vám rychleji najít i ty nejzákeřnější chyby.

Jak zorganizovat verzování kódu při více knihovnách - Revision history