Jak si zorganizovat složku s JavaScriptem, ať se v ní vyznáte

Co je adresář JavaScript souborů

Adresář JavaScript souborů je v podstatě obyčejná složka na disku nebo v rámci projektu, do které se ukládají soubory s příponou .js, tedy soubory obsahující kód napsaný v jazyce JavaScript. Na první pohled se může zdát, že jde o naprostou banalitu – vždyť co jiného by měla obsahovat složka pojmenovaná třeba „scripts“, „js“ nebo „source“ než právě skripty. Ve skutečnosti se ale za tímto jednoduchým označením skrývá docela důležitý organizační princip, na kterém stojí většina moderních webových i aplikačních projektů.

Když programátor začíná pracovat na webové stránce nebo aplikaci, velmi rychle zjistí, že psát veškerý kód do jednoho jediného souboru je nepraktické a dlouhodobě neudržitelné. Proto vzniká potřeba rozdělit kód do více souborů podle jejich funkce či účelu a tyto soubory pak logicky seskupit do adresářů. Adresář JavaScript souborů tak slouží jako místo, kde se soustřeďuje veškerá logika napsaná v tomto jazyce – ať už jde o validaci formulářů, práci s API, animace, nebo třeba obsluhu uživatelského rozhraní.

V praxi se s tímto adresářem setkáme téměř v každém webovém projektu. Bývá pojmenován různě, nejčastěji ale uvidíme názvy jako „js“, „scripts“, „javascript“ nebo v případě modernějších frameworků třeba „src“ či „components“, pokud jsou soubory JavaScriptu součástí širší struktury. Důležité je, že samotný název složky není nijak striktně vyžadován – jde spíše o zavedenou konvenci, kterou si vývojářská komunita postupem času osvojila, aby se v projektech dalo snadno orientovat.

Adresář JavaScript souborů má i praktický význam z hlediska propojení s HTML dokumentem. Pokud webová stránka potřebuje načíst určitý skript, obvykle na něj odkazuje pomocí cesty, která vede právě do této složky. Díky tomu je struktura webu přehlednější, protože všechny skripty jsou pohromadě a nemísí se s obrázky, styly nebo dalšími typy souborů. Tento přístup také výrazně usnadňuje údržbu – pokud je potřeba najít konkrétní funkci nebo opravit chybu, vývojář přesně ví, kam se má podívat.

V rozsáhlejších projektech se navíc adresář JavaScript souborů dále člení na podsložky, které oddělují jednotlivé moduly, komponenty nebo knihovny třetích stran. Typickým příkladem je oddělení vlastního kódu od externích knihoven, které se často ukládají do samostatné složky, aby nedocházelo k jejich míchání s kódem napsaným přímo pro daný projekt. Tato praxe je dnes běžná zejména díky rozšíření nástrojů pro správu závislostí, které generují vlastní strukturu adresářů pro knihovny a moduly.

Nelze také opomenout, že adresář JavaScript souborů hraje roli i při nasazování webových aplikací. Během tzv. buildovacího procesu se totiž často soubory z tohoto adresáře zpracovávají, minifikují a spojují do jednoho nebo několika výsledných souborů, které se pak nahrávají na server. I když tedy struktura složek během vývoje vypadá jinak než výsledná podoba nasazené aplikace, právě adresář JavaScript souborů je tím výchozím bodem, odkud celý proces začíná.

Typická struktura složky ve webovém projektu

Ve většině webových projektů se JavaScript soubory neschovávají chaoticky po celém repozitáři, ale mají svoje pevně dané místo, na které si zvykne každý, kdo s projektem pracuje déle než pár dní. Nejčastěji se setkáte s adresářem pojmenovaným src, což je zkratka od slova source, tedy zdroj. Uvnitř tohoto adresáře pak bývá podsložka js nebo přímo scripts, kam vývojáři ukládají veškerou logiku aplikace psanou v JavaScriptu. U starších projektů, které nevyužívají žádný build systém ani moderní frameworky, se často objevuje jednodušší struktura, kdy se soubory s příponou .js nacházejí přímo v kořenovém adresáři webu vedle HTML a CSS souborů, což ale u rozsáhlejších aplikací rychle přestává být přehledné.

U moderních projektů postavených na frameworcích jako React, Vue nebo Angular vypadá organizace o poznání sofistikovaněji. Typicky se setkáte s dělením podle funkce jednotlivých souborů, nikoliv jen podle jejich typu. Existuje tedy třeba složka components, kde jsou uloženy jednotlivé znovupoužitelné komponenty uživatelského rozhraní, dále složka utils nebo helpers obsahující pomocné funkce, které se využívají napříč celou aplikací, a často také složka services nebo api, kde se soustředí veškerá komunikace s backendem a externími rozhraními. Tento přístup, kdy se soubory dělí podle toho, co dělají, se v komunitě vývojářů označuje jako feature-based nebo domain-based struktura a je považován za výrazně udržitelnější než prosté třídění podle přípony souboru.

Nezanedbatelnou roli hraje i oddělení testovacích souborů od produkčního kódu. Velmi rozšířeným zvykem je vytvoření samostatné složky tests nebo __tests__, kam se ukládají jednotkové a integrační testy pro jednotlivé části JavaScriptového kódu. Někteří vývojáři preferují umístit testovací soubor přímo vedle testovaného souboru, což usnadňuje orientaci, ale zvyšuje počet souborů v jedné složce, jiní naopak dávají přednost oddělené hierarchii, která kopíruje strukturu zdrojového kódu.

Dalším typickým prvkem je adresář config, kde se nacházejí konfigurační soubory pro nástroje jako ESLint, Webpack, Babel nebo Vite, a také složka public nebo static, do které se ukládají statické zdroje, jež nejsou přímo součástí zpracovávaného JavaScriptového kódu, ale jsou pro fungování aplikace nezbytné.

Je důležité zmínit, že žádná z těchto struktur není univerzálně závazná a mnoho týmů si vytváří vlastní konvence podle velikosti a povahy projektu. Přesto se dá říct, že čitelnost, konzistence a předvídatelnost jsou hodnoty, které spojují prakticky všechny úspěšné přístupy k organizaci JavaScriptového kódu, a právě proto je vhodné se od začátku držet nějakého srozumitelného schématu, i kdyby šlo jen o drobný projekt.

Rozdíl mezi zdrojovými a sestavenými soubory

Když se otevře typický adresář obsahující JavaScriptový projekt, jen málokdy se v něm nachází výhradně to, co skutečně poběží v prohlížeči nebo na serveru. Většina moderních projektů rozlišuje mezi zdrojovými soubory, tedy tím, co píše programátor, a sestavenými (buildovanými) soubory, které vznikají až následným zpracováním a jsou určené ke skutečnému nasazení. Tento rozdíl je zásadní pro pochopení toho, jak se s takovou složkou pracuje, co se má a nemá verzovat, a proč se v projektu často objevují dvě až tři odlišné podoby téhož kódu.

Zdrojové soubory bývají zpravidla uloženy ve složce nazvané `src`, což je zkratka z anglického slova source. Právě zde programátor skutečně pracuje, upravuje logiku, přidává nové funkce a řeší chyby. Tyto soubory mohou obsahovat nejen čistý JavaScript, ale často i nadstavby a syntaxi, kterou běžný prohlížeč sám o sobě neumí interpretovat. Typickým příkladem je JSX používaný v knihovně React, TypeScript přidávající statické typování, nebo modernější syntaxe ECMAScriptu, kterou starší prostředí ještě nepodporují. Zdrojové soubory jsou tedy psány především s ohledem na čitelnost, udržovatelnost a pohodlí vývojáře, nikoliv na výkon či kompatibilitu.

Naproti tomu sestavené soubory vznikají až po průchodu takzvaným build procesem. Do hry vstupují nástroje jako Webpack, Vite, Rollup, Parcel nebo Babel, které zdrojový kód transformují, spojují do menšího počtu souborů, minifikují a optimalizují pro reálné nasazení. Výsledkem bývá složka s názvem `dist`, `build` nebo `out`, v níž se nachází kód zbavený komentářů, zbytečných mezer a často i sloučený do jednoho nebo několika málo souborů, aby se zkrátil počet síťových požadavků a zrychlilo se načítání stránky. Tento výstup je určen výhradně pro spotřebu strojem, respektive prohlížečem, a jeho čtení člověkem je záměrně nepohodlné.

Důležitým prvkem, který tyto dvě roviny propojuje, jsou source mapy. Jde o soubory s příponou `.map`, které umožňují i po minifikaci a sestavení dohledat, kterému řádku ve zdrojovém kódu odpovídá konkrétní místo v sestaveném souboru. Díky tomu je možné i v produkčním prostředí efektivně debugovat, aniž by bylo nutné pracovat přímo s nečitelným výstupem.

Z praktického hlediska se běžně doporučuje, aby se do verzovacího systému, jako je Git, ukládaly pouze zdrojové soubory, zatímco sestavené výstupy se generují automaticky při buildu nebo nasazení a bývají vyloučeny pomocí souboru `.gitignore`. Tím se předchází zbytečnému duplikování obsahu a konfliktům, které by vznikaly při každé změně generovaného kódu. Sestavené soubory tak představují spíše dočasný, opakovaně vytvářený artefakt než trvalou součást projektové historie, zatímco zdrojové soubory zůstávají skutečným jádrem a jedinou spolehlivou pravdou o tom, jak aplikace funguje.

Význam souborů package.json a node_modules

Každý projekt napsaný v JavaScriptu, ať už jde o jednoduchý skript nebo rozsáhlou webovou aplikaci, dříve nebo později narazí na soubor s názvem package.json. Tento soubor tvoří samotné srdce celého projektu a bez něj by se moderní vývoj v Node.js prostředí prakticky neobešel. Package.json v podstatě funguje jako identifikační karta a zároveň manuál celého adresáře se zdrojovým kódem. Obsahuje totiž základní informace o projektu, jako je jeho název, verze, autor, licence a stručný popis, ale to je jen ta méně důležitá část. Klíčovou roli hraje především seznam závislostí, tedy externích knihoven a balíčků, které projekt potřebuje ke svému fungování. Díky tomuto seznamu si může kdokoliv jiný, kdo si projekt stáhne, jednoduše doinstalovat všechny potřebné součásti a rozjet aplikaci na svém počítači bez dlouhého pátrání po tom, co je vlastně potřeba.

Vedle samotných závislostí package.json obsahuje také takzvané skripty, což jsou příkazy, které si vývojář nadefinuje a následně je může spouštět jediným příkazem z terminálu. Typickým příkladem je spuštění vývojového serveru, sestavení produkční verze aplikace nebo spuštění testů. Tato automatizace šetří spoustu času a zajišťuje, že se všichni členové týmu držou stejného postupu. Package.json tak funguje jako centrální bod, kolem kterého se celý projekt organizuje, a bez jeho existence by správa jakéhokoliv většího JavaScriptového projektu byla mnohem komplikovanější a chaotičtější.

S package.json je velmi těsně spjatá složka node_modules, která se v adresáři projektu objeví ve chvíli, kdy vývojář zadá příkaz pro instalaci závislostí. Tato složka obsahuje veškerý kód knihoven a balíčků, které si projekt vyžádal v package.json, a to včetně všech jejich vlastních závislostí, které si tyto knihovny potřebují pro svůj vlastní chod. Výsledkem je často velmi rozsáhlá a hluboce zanořená struktura souborů, která může snadno obsahovat desítky tisíc jednotlivých souborů, i když samotný projekt je poměrně malý. Právě proto se node_modules v praxi téměř nikdy nenahrává do verzovacích systémů jako je Git, protože by to zbytečně zatěžovalo repozitář a navíc by to bylo redundantní, jelikož si každý může tuto složku znovu vygenerovat pomocí package.json.

Důležité je také zmínit soubor package-lock.json, který se vytváří automaticky společně se složkou node_modules. Tento soubor zaznamenává přesné verze všech nainstalovaných balíčků, díky čemuž je zajištěno, že se na různých počítačích nebo serverech nainstaluje naprosto identická sada závislostí. To výrazně přispívá ke stabilitě a předvídatelnosti chodu aplikace, protože se eliminuje riziko, že by se na jiném stroji stáhla novější a případně nekompatibilní verze některé knihovny.

Organizace komponent, modulů a knihoven

Uspořádání složky s JavaScriptovým kódem se v praxi vždy odvíjí od toho, jak jsou v projektu rozdělené komponenty, moduly a knihovny, a právě tato struktura rozhoduje o tom, jestli se v kódu bude dát po měsíci ještě vyznat, nebo jestli se z něj stane nepřehledná změť souborů. Ve větších aplikacích, ať už postavených na Reactu, Vue nebo Angularu, se ukazuje jako výhodné oddělovat jednotlivé vrstvy podle jejich funkce, nikoliv podle typu souboru. Znamená to, že namísto jedné velké složky s komponentami a druhé se styly se často volí přístup, kdy má každá funkční část aplikace svoji vlastní podsložku obsahující komponentu, její styly, testy a případně i lokální pomocné funkce. Tento způsob organizace se označuje jako feature-based struktura a v praxi se osvědčuje hlavně u projektů, které postupem času rostou a přibývají do nich nové funkce.

Moduly, tedy samostatné soubory nebo skupiny souborů, které řeší konkrétní logiku nezávisle na uživatelském rozhraní, bývají obvykle umístěny odděleně od komponent. Typicky se pro ně vyhrazuje složka nazvaná třeba utils, helpers nebo services, kde se soustředí funkce pro práci s daty, validace, komunikaci s API nebo formátování textu. Díky tomu, že jsou tyto moduly oddělené od vizuální vrstvy aplikace, je možné je snadno testovat samostatně a případně i sdílet mezi různými částmi projektu bez zbytečného kopírování kódu. Dobře navržený modul by měl mít jasně definovaný účel a co nejméně závislostí na jiných částech kódu, protože jen tak si zachová svoji znovupoužitelnost.

Knihovny, ať už externí, stažené přes balíčkovací systém jako je npm nebo yarn, nebo interní, vytvořené přímo pro potřeby daného projektu, si zaslouží ještě přísnější oddělení. Externí knihovny se instalují do složky node_modules, se kterou se v běžné praxi nepracuje ručně a která se ani nenahrává do verzovacího systému. Naproti tomu interní knihovny, tedy vlastní sady funkcí nebo komponent určené k opakovanému použití napříč projektem, se často umisťují do složky s názvem lib nebo shared, aby bylo na první pohled jasné, že jde o kód, který není vázaný na konkrétní obrazovku nebo funkci aplikace.

Velmi důležitým prvkem organizace je také konzistentní pojmenování souborů a složek, protože v týmu, kde na projektu pracuje více lidí, se rychle projeví, pokud každý pojmenovává soubory jinak. Zavedení jasných pravidel, ideálně popsaných přímo v dokumentaci projektu, výrazně usnadňuje orientaci novým členům týmu i údržbu kódu v delším časovém horizontu. Stejně tak se vyplácí důsledně oddělovat testovací soubory od produkčního kódu, ať už pomocí přípony jako .test.js, nebo umístěním do samostatné složky tests. Přehledná a logická struktura složek tak není jen otázkou estetiky, ale přímo ovlivňuje rychlost vývoje, snadnost údržby a schopnost projektu růst bez zbytečných komplikací.

Konvence pojmenování souborů a složek

V praxi se organizace JavaScriptového projektu neobejde bez důsledného dodržování konvencí pro pojmenování souborů a složek, protože právě tady se často rozhoduje o tom, jestli se v kódu bude po měsících či letech ještě někdo schopen rychle zorientovat. Zkušení vývojáři vědí, že konzistence je důležitější než konkrétní zvolený styl – tedy jestli se nakonec rozhodnete pro kebab-case, camelCase nebo snake_case, není tak zásadní jako to, že se daného rozhodnutí budete držet napříč celým projektem.

Nejrozšířenější konvencí pro pojmenování souborů v JavaScriptu je bezesporu kebab-case, tedy zápis s pomlčkami místo mezer, například user-profile.js nebo shopping-cart-service.js. Tento styl je oblíbený zejména proto, že se vyhýbá problémům s rozlišováním velkých a malých písmen, které se mohou lišit mezi operačními systémy – zatímco Windows běžně nerozlišuje mezi UserProfile.js a userprofile.js, na Linuxu jde o dva zcela odlišné soubory. Právě tato drobnost dokáže způsobit nepříjemné chyby při nasazování aplikace na server s jiným operačním systémem, než na jakém probíhal vývoj.

Pokud jde o soubory obsahující definici React komponent, zde se často setkáváme s odlišnou konvencí – PascalCase, kdy název souboru odpovídá názvu exportované komponenty, například UserCard.jsx nebo NavigationMenu.tsx. Tento přístup dává smysl především proto, že usnadňuje okamžitou identifikaci, co daný soubor obsahuje, a zároveň koresponduje s konvencí pojmenování samotných komponent v kódu.

Co se týče složek, i zde platí, že přehlednost a předvídatelnost jsou klíčové. Běžnou praxí je používat malá písmena a pomlčky i pro názvy adresářů, takže výsledná struktura projektu může vypadat například takto: components, utils, api-services, shared-hooks. Důležité je také rozlišovat mezi složkami podle jejich funkce v aplikaci – tedy oddělovat logiku byznysu od komponent uživatelského rozhraní, pomocné funkce od konfiguračních souborů a testovací soubory od produkčního kódu.

Mnoho týmů preferuje umisťovat testovací soubory přímo vedle testovaného kódu, přičemž se v názvu objevuje přípona .test.js nebo .spec.js, například calculateTotal.test.js. Tento přístup zvyšuje viditelnost testů a usnadňuje jejich údržbu, protože vývojář nemusí přecházet mezi vzdálenými částmi adresářové struktury.

Neméně důležitým aspektem je také pojmenování konfiguračních a pomocných souborů, jako jsou index.js, které slouží jako vstupní bod modulu nebo složky. Tento soubor bývá zvykem používat pro reexportování obsahu složky, což zjednodušuje importy v jiných částech aplikace.

Za zmínku stojí i oddělování zdrojového kódu od sestaveného výstupu – typicky se pro zdrojové soubory používá složka src, zatímco výsledný zkompilovaný kód putuje do složky dist nebo build. Toto rozdělení není pouze estetickou záležitostí, ale má praktický dopad na verzování projektu, protože composed výstupy se obvykle do repozitáře vůbec nenahrávají a jsou generovány automaticky během sestavovacího procesu.

Dodržování jasně definovaných a v týmu odsouhlasených konvencí nakonec šetří čas všem, kdo s kódem pracují, a výrazně snižuje riziko chyb způsobených nejednotností napříč projektem.

JavaScript je jako složka plná souborů, kde se v tichosti odehrává celý příběh aplikace – stačí otevřít správný adresář a najdeš tam mapu k jejímu srdci.

Bohumil Vraštil

Use bundlerů jako Webpack nebo Vite

Ve chvíli, kdy projekt narůstá a v adresáři se souborem JavaScriptu přibývá modulů, komponent a závislostí, přestává být rozumné spoléhat se na to, že prohlížeč si se vším poradí sám. Právě tady přichází na řadu bundlery, tedy nástroje, které dokážou celou strukturu složky s kódem projít, pochopit vazby mezi jednotlivými soubory a poskládat z nich výsledný balíček určený k nasazení. Mezi nejrozšířenější zástupce této kategorie patří Webpack a Vite, přičemž oba řeší v zásadě podobný problém, ale každý trochu jiným způsobem.

Webpack se na scéně objevil jako odpověď na chaos, který nastal, když se webové aplikace začaly skládat z desítek až stovek JavaScriptových souborů, obrázků, stylů a dalších zdrojů. Jeho síla spočívá v tom, že dokáže z celé adresářové struktury vytvořit jeden nebo několik optimalizovaných výstupních souborů, které se pak nahrají na server. Díky systému loaderů a pluginů umí zpracovat nejen čistý JavaScript, ale i TypeScript, CSS, obrázky nebo fonty, což z něj dělá univerzální nástroj vhodný pro rozsáhlé a komplexní projekty. Nevýhodou bývá poměrně složitá konfigurace, která může nováčka na první pohled odradit, a také pomalejší reakce při vývoji, protože Webpack musí při každé změně znovu sestavit relevantní části bundlu.

Vite naproti tomu vznikl jako reakce na rostoucí požadavky vývojářů na rychlost. Využívá nativní podporu ES modulů přímo v prohlížeči, takže během vývoje nemusí sestavovat celou aplikaci najednou, ale pouze ty části, které jsou zrovna potřeba. To se projevuje téměř okamžitým načtením vývojového serveru i bleskovou reakcí na uložené změny v kódu. Pro produkční nasazení pak Vite interně využívá nástroj Rollup, který zajistí, že výsledný balíček je stejně efektivní a optimalizovaný jako u tradičních řešení. Tento přístup výrazně zjednodušuje práci s adresářovou strukturou projektu, protože vývojář se nemusí tolik starat o to, jak jsou jednotlivé soubory propojené, a může se soustředit na samotný kód.

Výběr mezi Webpackem a Vite se dnes často odvíjí od velikosti a charakteru projektu. Zatímco Webpack zůstává silnou volbou pro rozsáhlé aplikace s netypickými požadavky na sestavení, kde je potřeba jemné doladění každého detailu, Vite se stal oblíbenou volbou pro moderní frontendové projekty, kde je rychlost vývoje klíčová. Oba nástroje ale sdílejí společný cíl, a to proměnit rozsáhlou a často nepřehlednou složku plnou JavaScriptových souborů v přehledný, funkční a rychle načitatelný celek, se kterým se dá efektivně pracovat jak během vývoje, tak při finálním nasazení do produkčního prostředí.

Testovací soubory a jejich umístění

Při organizaci JavaScriptového projektu představuje otázka umístění testovacích souborů jedno z nejčastěji diskutovaných témat mezi vývojáři. Existují v podstatě dva hlavní přístupy a oba mají své pevné zastánce i odpůrce. Prvním z nich je umístění testů přímo vedle testovaného souboru, tedy do stejné složky jako zdrojový kód. Druhým přístupem je vytvoření samostatné centrální složky, obvykle pojmenované tests nebo __tests__, kam se soustředí veškeré testovací soubory bez ohledu na to, kde se nachází testovaný kód.

Přístup, kdy test leží přímo vedle komponenty nebo modulu, se v poslední době těší velké oblibě, zejména v projektech postavených na frameworcích jako React nebo Vue. Pokud máte soubor Button.js, jeho test se pak jmenuje Button.test.js nebo Button.spec.js a leží ve stejném adresáři. Tato konvence usnadňuje orientaci, protože při otevření složky okamžitě vidíte, zda daná komponenta má test, a nemusíte přepínat mezi vzdálenými částmi adresářové struktury. Nevýhodou může být přeplněnost složek, kdy se v jedné složce mísí zdrojové soubory s testovacími, což některým týmům vadí z hlediska přehlednosti.

Druhý přístup, tedy centralizovaná složka __tests__, je typický pro nástroje jako Jest, který tuto konvenci automaticky rozpoznává a spouští testy nalezené v jakékoli složce s tímto názvem, ať už je umístěná na kořenové úrovni projektu, nebo vnořená hlouběji ve struktuře. Tento přístup oceňují zejména větší týmy, protože jasně odděluje testovací logiku od produkčního kódu a usnadňuje správu přístupových práv nebo konfiguraci nástrojů, které mají testy ignorovat při sestavování produkční verze aplikace.

Kromě těchto dvou základních variant se v praxi často setkáváme i s hybridním řešením, kdy jednotkové testy zůstávají vedle zdrojového kódu, zatímco integrační nebo end-to-end testy se přesouvají do samostatné složky, typicky nazvané e2e nebo integration. Tento model dává smysl, protože jednotkové testy úzce souvisí s konkrétním modulem a jejich blízkost usnadňuje refaktoring, zatímco end-to-end testy pokrývají celé toky aplikace napříč více soubory a logicky patří mimo strukturu jednotlivých komponent.

Volba konkrétního přístupu by měla vycházet z velikosti projektu, počtu členů týmu a použitých nástrojů. Malé projekty s jedním nebo dvěma vývojáři často vystačí s jednoduchým umístěním testů vedle kódu, zatímco rozsáhlé aplikace s desítkami přispěvatelů obvykle profitují z jasně definované a centralizované struktury, která je zdokumentovaná v interních konvencích projektu. Důležité je také zohlednit konfiguraci testovacího frameworku, protože nástroje jako Jest, Vitest nebo Mocha mají své výchozí vzory pro vyhledávání testovacích souborů a odchýlení se od nich vyžaduje dodatečnou konfiguraci v souboru package.json nebo v samostatném konfiguračním souboru daného nástroje.

Správa závislostí a verzování kódu

Ve chvíli, kdy se JavaScriptový projekt rozroste za hranice jednoho souboru s pár funkcemi, přestává být organizace kódu do složek jen kosmetickou záležitostí a stává se otázkou přežití celého projektu. Typická struktura adresáře s JavaScriptovým kódem dnes zahrnuje složku node_modules, kde se ukládají všechny externí knihovny a balíčky, na kterých aplikace závisí. Tato složka bývá obvykle tak rozsáhlá, že se do verzovacího systému vůbec nenahrává a místo toho se řídí souborem, který definuje přesný seznam závislostí a jejich verzí.

Klíčovým souborem v tomto ohledu je package.json, který funguje jako jakýsi rodný list projektu. Obsahuje nejen název a verzi aplikace, ale především seznam všech balíčků, na kterých kód staví, včetně rozlišení mezi produkčními závislostmi a těmi, které jsou potřeba jen během vývoje, testování nebo sestavování aplikace. Vedle něj existuje soubor package-lock.json nebo v případě jiných správců balíčků yarn.lock či pnpm-lock.yaml, jenž zamyká přesné verze všech závislostí včetně těch vnořených, takže se dá zaručit, že aplikace poběží stejně na počítači vývojáře i na produkčním serveru. Bez tohoto zámykacího souboru by se mohlo stát, že se stejný projekt na dvou různých strojích chová odlišně, protože by se stáhly mírně odlišné verze knihoven.

Správci balíčků jako npm, yarn nebo modernější pnpm nejenže stahují a instalují potřebné knihovny, ale také řeší složitou síť závislostí mezi nimi, kdy jeden balíček může vyžadovat desítky dalších. Právě proto je důsledné verzování podle sémantických pravidel tak důležité – čísla verze ve formátu major.minor.patch napovídají, zda jde o zásadní změnu, která může rozbít zpětnou kompatibilitu, o přidání nové funkcionality, nebo jen o opravu chyby.

Pokud jde o samotné verzování zdrojového kódu, drtivá většina JavaScriptových projektů dnes spoléhá na Git jako distribuovaný systém správy verzí. Struktura složek se obvykle doplňuje o soubor .gitignore, který určuje, jaké soubory a adresáře se do repozitáře vůbec nemají zahrnovat – typicky právě zmíněná složka node_modules, sestavené výstupy z build procesu, dočasné soubory editoru nebo citlivé konfigurační soubory obsahující hesla a klíče k API. Ignorování zbytečných souborů udržuje repozitář přehledný a šetří místo i čas při klonování projektu.

Samostatnou kapitolou je práce s větvemi a takzvaný branching model, kdy se hlavní větev, často nazývaná main nebo master, udržuje ve stabilním stavu, zatímco vývoj nových funkcí probíhá v oddělených větvích, které se po dokončení a otestování slučují zpět. K tomu se přidávají nástroje pro automatizaci, jako jsou Git hooky nebo integrace s CI/CD nástroji, které při každém commitu ověří, zda kód splňuje stanovená pravidla formátování a zda neobsahuje zjevné chyby. Celý tento systém, kombinující strukturu složek, správu balíčků a verzovací nástroje, tvoří páteř, díky které lze i rozsáhlý JavaScriptový projekt s desítkami přispěvatelů udržet přehledný, funkční a bezpečně rozvíjet dál.

Bezpečnostní rizika ve sdílených adresářích

Sdílené adresáře, ve kterých se ukládá zdrojový kód napsaný v JavaScriptu, představují z bezpečnostního hlediska mnohem citlivější oblast, než by se na první pohled mohlo zdát. JavaScript je jazyk, který se běžně spouští přímo v prohlížeči uživatele, a pokud se do sdíleného adresáře dostane škodlivý nebo pozměněný soubor, může se jeho vliv projevit nečekaně rychle a na mnoha místech najednou. Právě proto je otázka řízení přístupu ke složkám s kódem jednou z prvních věcí, kterou by měl každý vývojářský tým řešit ještě předtím, než začne pracovat na společném projektu.

Základním problémem bývá nedostatečně nastavená správa oprávnění. Pokud má ke sdílené složce přístup příliš mnoho lidí, nebo pokud práva k zápisu dostanou i ti, kteří je ve skutečnosti nepotřebují, roste riziko, že se do kódu dostane chyba, zranitelnost, nebo dokonce úmyslně vložený škodlivý úsek. U JavaScriptu je toto riziko o to výraznější, že jazyk umožňuje dynamické načítání a spouštění externích skriptů, což znamená, že i drobná úprava jednoho souboru může otevřít cestu k spuštění libovolného kódu na straně klienta.

Dalším citlivým místem je práce se závislostmi a balíčky, které se často ukládají právě do sdílených adresářů projektu. Pokud tým nemá zavedenou kontrolu nad tím, odkud a jak se knihovny stahují, hrozí, že se do projektu dostane kompromitovaný balíček, jenž následně ovlivní celou aplikaci. Tento typ útoku bývá obtížně odhalitelný, protože škodlivý kód se často skrývá hluboko ve vnořených závislostech a na povrchu vypadá vše zcela běžně.

Riziko představuje také samotné sdílení citlivých údajů v rámci adresářové struktury. Vývojáři někdy z pohodlnosti ukládají přístupové klíče, hesla nebo konfigurační soubory přímo do stejné složky, kde se nachází zdrojový kód. Pokud je tento adresář sdílený přes cloudové úložiště nebo verzovací systém s širším okruhem spolupracovníků, citlivé informace se mohou snadno dostat k nepovolaným osobám. Bezpečné oddělení konfigurace od zdrojového kódu proto patří mezi zásadní doporučení, které by neměl podceňovat žádný tým pracující s JavaScriptem.

Neméně důležitá je i otázka verzování a auditní stopy. Bez jasného přehledu o tom, kdo a kdy provedl jakou změnu, je téměř nemožné zpětně zjistit, odkud se do sdíleného adresáře dostal problematický kód. Pravidelné revize historie změn, kontrola commitů a nastavení notifikací při podezřelých úpravách pomáhají odhalit potenciální hrozbu dříve, než se stihne projevit v produkčním prostředí.

V neposlední řadě je třeba myslet na to, že sdílené adresáře bývají často synchronizovány mezi více zařízeními a platformami. Pokud jedno z nich není dostatečně zabezpečené, stává se slabým článkem celého řetězce. Kombinace silného ověřování, šifrovaného přenosu dat a pravidelné aktualizace nástrojů proto tvoří základ, na kterém by měla stát každá bezpečná spolupráce nad kódem psaným v JavaScriptu.

Nástroje pro analýzu a čištění kódu

Kvalita zdrojového kódu v projektech postavených na JavaScriptu se dnes už neposuzuje jen podle toho, jestli aplikace funguje. Rozhodující roli hraje udržovatelnost, čitelnost a konzistence napříč celou složkou souborů, ať už jde o malý skript nebo rozsáhlý projekt s desítkami modulů. Právě proto se v běžné praxi vývojářů usadila sada nástrojů, které dokážou kód automaticky analyzovat, odhalovat chyby ještě před spuštěním a v mnoha případech je i rovnou opravit.

Základním kamenem této kategorie je ESLint, statický analyzátor, který prochází veškeré soubory s příponou .js (případně .jsx nebo .ts, pokud je projekt rozšířen o TypeScript) a kontroluje je proti sadě pravidel. Tato pravidla si lze nastavit podle vlastních preferencí týmu, nebo použít některý z rozšířených konfiguračních standardů, jako je Airbnb, Standard nebo doporučená sada přímo od tvůrců ESLintu. Nástroj dokáže upozornit na nepoužité proměnné, chybějící středníky tam, kde je konvence vyžaduje, potenciálně nebezpečné porovnávání pomocí volné rovnosti nebo na zapomenuté console.log příkazy, které by neměly skončit v produkčním kódu. Velkou výhodou je, že ESLint lze napojit přímo na editor kódu, takže se chyby zobrazují v reálném čase během psaní, což výrazně zrychluje celý vývojový proces.

Druhým klíčovým hráčem je Prettier, formátovací nástroj, který se nesoustředí na logické chyby, ale výhradně na vzhled kódu. Sjednocuje odsazení, délku řádků, používání uvozovek nebo umístění závorek tak, aby veškeré soubory ve složce projektu vypadaly, jako by je psal jeden člověk, i když na nich pracuje celý tým. Kombinace ESLintu a Prettieru se stala prakticky standardem, protože první se stará o kvalitu a bezpečnost kódu, zatímco druhý zajišťuje jeho estetickou konzistenci.

Pro hlubší analýzu struktury a komplexity kódu se často sahá po nástrojích jako JSHint nebo JSCS, které sice dnes už nejsou tak rozšířené jako dříve, ale v některých starších nebo specifických projektech se s nimi lze stále setkat. Zajímavou alternativou je také SonarQube, který jde ještě dál a nabízí komplexní přehled o technickém dluhu, duplicitách v kódu nebo bezpečnostních zranitelnostech napříč celou složkou zdrojových souborů, nikoliv jen jednotlivými soubory.

Nezanedbatelnou součástí čištění kódu jsou i nástroje zaměřené na odstraňování nepoužívaného kódu, takzvaný dead code, kdy se analyzují importy a exporty mezi jednotlivými moduly a hledají se části, které už nikde nejsou volané. To je obzvlášť užitečné u větších projektů, kde se v průběhu času nahromadí spousta zbytečného kódu, jenž zbytečně zvětšuje výsledný balíček a zpomaluje načítání aplikace.

Většina těchto nástrojů se dnes zapojuje přímo do procesu automatizovaného sestavování, takzvaného CI/CD, kde se kontrola kódu spouští automaticky při každém uložení změn do repozitáře. Díky tomu se chybný nebo nekonzistentní kód nedostane do hlavní větve projektu, což šetří čas i nervy celému vývojářskému týmu.

Doporučené postupy pro udržitelnost projektu

Udržitelnost projektu psaného v JavaScriptu se v praxi odvíjí především od toho, jak je organizovaná samotná složka nebo adresář souborů kódu, protože pokud se struktura zanedbá hned na začátku, každý další měsíc vývoje se prodraží na čase i nervech celého týmu. Zkušení vývojáři proto věnují pozornost tomu, aby adresářová struktura odpovídala logice aplikace a ne aktuálnímu rozmaru toho, kdo zrovna commituje. Konzistentní organizace složek podle funkčních celků, například rozdělení na komponenty, služby, utility a testy, umožňuje novým lidem v týmu se v projektu zorientovat během několika hodin, nikoliv dnů. Je také užitečné oddělit zdrojový kód od buildovaných výstupů a konfiguračních souborů, protože smíchání těchto vrstev vede dříve nebo později k chaosu při nasazování i při verzování.

Dalším pilířem udržitelnosti je disciplína v pojmenovávání souborů a složek. Když se v projektu objeví desítky souborů s podobnými, ale ne úplně shodnými názvy, hledání konkrétní funkčnosti se stává detektivní prací. Jednotná konvence pojmenování, ať už se týmy rozhodnou pro camelCase, kebab-case nebo jinou variantu, by měla být zapsaná v dokumentaci projektu a dodržovaná bez výjimek. Stejně důležité je nepřehánět hloubku zanoření adresářů, protože přílišná fragmentace kódu do desítek podsložek často znesnadňuje navigaci víc, než kolik přináší přehlednosti.

Udržitelnost projektu se ale neomezuje jen na fyzické uspořádání souborů. Zásadní roli hraje i to, jak se v adresáři JavaScriptového kódu zachází se závislostmi. Pravidelná aktualizace knihoven a balíčků spravovaných přes npm nebo yarn patří mezi činnosti, které se snadno odkládají, ale jejich zanedbání vede k bezpečnostním rizikům a k situaci, kdy je aktualizace po roce či dvou téměř nemožná bez rozsáhlého refaktoringu. Proto se doporučuje mít nastavené automatické kontroly zranitelností a průběžně sledovat, jaké závislosti se v projektu skutečně používají, protože nepoužívaný kód a zbytečné balíčky jen zvyšují velikost projektu a riziko konfliktů.

Nezastupitelnou roli hraje také psaní testů a jejich umístění v rámci adresářové struktury. Testy by měly být snadno dohledatelné a měly by kopírovat strukturu testovaného kódu, což usnadňuje údržbu v okamžiku, kdy se měně funkčnost a je potřeba rychle najít odpovídající testovací soubor. Dokumentace přímo v kódu, ať formou komentářů nebo generovaných dokumentů, dále snižuje závislost projektu na jednotlivcích, kteří by jinak byli jedinými nositeli znalostí o tom, jak co funguje.

V neposlední řadě je vhodné myslet na konzistentní formátování kódu pomocí nástrojů jako ESLint nebo Prettier, které se nastaví jednou pro celý repozitář a pak automaticky vynucují stejný styl u všech přispěvatelů. Tím se předchází zbytečným diskuzím o stylistice a energie týmu se může soustředit na skutečnou funkčnost a dlouhodobou udržitelnost celého projektu.