Jak si v roce 2026 přehledně uspořádat složku s JavaScriptem

Co je adresář JavaScript souborů

Adresář JavaScript souborů je v podstatě obyčejná složka v souborovém systému, do které vývojáři ukládají soubory s příponou .js, tedy soubory obsahující zdrojový kód napsaný v jazyce JavaScript. Na první pohled se může zdát, že jde o naprostou banalitu – vždyť složka je jen složka, ať už v ní leží fotky z dovolené nebo textové dokumenty. U programování to ale funguje trochu jinak, protože struktura adresářů přímo ovlivňuje to, jak se aplikace chová, jak rychle se dá v kódu orientovat a jak snadno se s ním dále pracuje. V roce 2026 je toto téma stále aktuální, protože i s rozvojem moderních frameworků a nástrojů typu Vite, Next.js nebo Astro zůstává základní princip organizace souborů stejný – kód je potřeba nějak logicky rozdělit a uložit.

Když si vývojář vytváří nový projekt, ať už jde o jednoduchou webovou stránku nebo rozsáhlou aplikaci, téměř vždy narazí na potřebu oddělit JavaScript kód od zbytku projektu. Typicky se proto zakládá adresář nazvaný například „js“, „scripts“ nebo v modernějších projektech „src“, do kterého se ukládají všechny soubory obsahující logiku aplikace. Díky tomu není nutné prohledávat celý projekt, pokud potřebujete upravit konkrétní funkci nebo najít chybu – stačí nahlédnout do příslušné složky, kde se očekává výskyt relevantního kódu.

Důležité je zmínit, že adresář JavaScript souborů nemusí být plochý, tedy že v něm neleží všechny soubory na jedné úrovni bez jakéhokoli řádu. Naopak, ve větších projektech se běžně vytváří hierarchická struktura podadresářů, kde se rozlišují například komponenty, pomocné funkce, konfigurační soubory nebo testy. Tento přístup usnadňuje škálovatelnost projektu a umožňuje více lidem pracovat na stejném kódu bez zbytečných konfliktů.

Za zmínku stojí také to, že samotný pojem „adresář JavaScript souborů“ může znamenat jak fyzickou složku na disku počítače vývojáře, tak i strukturu uvnitř repozitáře na platformách jako GitHub nebo GitLab. V obou případech ale platí stejná logika – jde o místo, kde se soustřeďuje zdrojový kód psaný v JavaScriptu, oddělený od jiných typů souborů, jako jsou styly CSS nebo obrázky.

V praxi tedy adresář JavaScript souborů slouží především k tomu, aby udržoval pořádek v projektu a usnadňoval práci nejen jednotlivci, ale i celému týmu. Bez jasně definované struktury by se i menší projekt mohl velmi rychle stát nepřehledným a obtížně udržovatelným, což by v konečném důsledku zpomalovalo vývoj a zvyšovalo riziko chyb.

Typická struktura složky v roce 2026

V roce 2026 se struktura složky obsahující JavaScriptový kód proměnila natolik, že ji dnes jen málokdo pozná v podobě, jakou znal třeba před pěti nebo deseti lety. Zatímco dřív stačilo mít v projektu jeden soubor s příponou .js a odkázat se na něj přímo z HTML dokumentu, dnešní projekty jsou mnohem propracovanější a jejich organizace odráží nároky na škálovatelnost, týmovou spolupráci i automatizované nasazení. Kořenový adresář typického JavaScriptového projektu dnes obsahuje soubor package.json, který definuje závislosti, skripty a metadata celého balíčku, doplněný o package-lock.json nebo alternativně pnpm-lock.yaml.eslintrc nebo jeho novější varianta ve formátu plochého konfiguračního souboru, dále .prettierrc pro jednotné formátování kódu a soubor tsconfig.json, pokud projekt využívá TypeScript, což je v roce 2026 spíše pravidlem než výjimkou.

Samotný zdrojový kód se dnes téměř vždy nachází ve speciální složce nazvané src, uvnitř níž panuje logická hierarchie odpovídající architektuře aplikace. Běžně tam najdeme podsložky jako components pro znovupoužitelné komponenty, hooks pro vlastní React hooky nebo jejich obdoby v jiných frameworcích, utils nebo helpers pro pomocné funkce, services nebo api pro komunikaci s backendem a store nebo state pro správu stavu aplikace pomocí knihoven typu Zustand, Redux Toolkit nebo Jotai. Tato modulární struktura umožňuje vývojářům rychle se orientovat i ve velmi rozsáhlých projektech a usnadňuje testování jednotlivých částí odděleně od zbytku aplikace.

Nedílnou součástí moderní složky s JavaScriptovým kódem je také adresář tests nebo přímo testovací soubory umístěné vedle zdrojového kódu s příponou .test.js nebo .spec.ts, což odráží rostoucí důraz na automatizované testování pomocí nástrojů jako Vitest nebo Jest. Vedle toho se v kořenovém adresáři často objevuje složka public se statickými soubory, dist nebo build generovaná automaticky při sestavení projektu a v neposlední řadě adresář .github s definicemi workflow pro kontinuální integraci, jelikož automatizace nasazení je dnes standardem i u menších týmů.

Zajímavé je, že v roce 2026 se stále více projektů přiklání k takzvané monorepo struktuře, kde jedna složka obsahuje více souvisejících balíčků najednou, spravovaných nástroji jako Turborepo nebo Nx. Díky tomu vzniká uvnitř kořenového adresáře další úroveň organizace, typicky složka packages nebo apps, která sdružuje jednotlivé části většího systému. Tento přístup výrazně mění to, jak vývojáři přemýšlejí o hranicích jednotlivých projektů a jak sdílejí kód mezi frontendem, backendem i mobilními aplikacemi postavenými na JavaScriptu.

Rozdíl mezi src a dist složkou

Když se ponoříte do struktury jakéhokoliv modernějšího JavaScriptového projektu, téměř vždy narazíte na dvě klíčové složky, které na první pohled mohou vypadat podobně, ale ve skutečnosti mají zcela odlišný účel. Jedná se o složky src a dist, jejichž rozdíl je pro pochopení vývojového procesu naprosto zásadní.

Složka src, což je zkratka od anglického slova „source“, obsahuje zdrojový kód aplikace v té podobě, v jaké jej programátor skutečně píše. Najdete zde soubory s příponou .js, případně .jsx nebo .ts, pokud se pracuje s JSX syntaxí nebo s TypeScriptem, dále soubory se styly, komponenty, moduly a veškerou logiku, kterou vývojářský tým do projektu postupně přidává. Tento kód je psán s ohledem na čitelnost, udržovatelnost a spolupráci v týmu – obsahuje komentáře, je formátovaný, rozdělený do menších logických celků a často využívá moderní syntaxi, kterou ne všechny prohlížeče musí nutně podporovat. Právě proto se tento kód nikdy nenasazuje přímo do produkčního prostředí v nezměněné podobě.

Naproti tomu složka dist, odvozená od slova „distribution“, obsahuje výsledný, zpracovaný kód, který vznikl automatizovaným procesem sestavení, tedy tzv. buildu. Tento proces obvykle zajišťují nástroje jako Webpack, Vite, Rollup nebo Parcel, které zdrojové soubory ze složky src transformují, minifikují, spojují do menšího počtu souborů a případně i transpilují pomocí nástrojů jako Babel, aby byl výsledný kód spustitelný i ve starších prohlížečích. Obsah složky dist je tedy optimalizovaný pro rychlost načítání a výkon, nikoliv pro lidskou čitelnost – proměnné mají často zkrácené názvy, odsazení a komentáře zcela chybí a celý kód je zhuštěn do co nejmenšího množství bajtů.

Důležité je zmínit, že složka dist se v běžné praxi nikdy neupravuje manuálně. Jakákoliv změna provedená přímo v této složce by byla při dalším sestavení projektu automaticky přepsána, protože dist vzniká vždy znovu na základě aktuálního obsahu složky src. Z tohoto důvodu se také dist složka velmi často nepřidává do verzovacího systému, jako je Git, a bývá uvedena v souboru .gitignore. Naopak složka src je srdcem celého repozitáře a je to právě ona, se kterou vývojáři denně pracují, testují ji, upravují a posílají do sdíleného úložiště.

Tento rozdíl má i praktický dopad na celý vývojový cyklus. Zatímco src reprezentuje živý, neustále se měnící stav projektu, dist představuje statický snímek, který je určen k nasazení na server nebo k publikaci jako hotový balíček, například v případě knihoven publikovaných přes npm. Pro koncového uživatele webové stránky nebo aplikace je tak v konečném důsledku relevantní pouze obsah složky dist, avšak veškerá skutečná práce, inovace a údržba probíhá výhradně ve složce src.

Organizace modulů a komponent

Uspořádání souborů JavaScriptu do promyšlené adresářové struktury patří k základním dovednostem, které odlišují udržovatelný projekt od chaotického klubka kódu. Když se podíváte na typický moderní projekt v roce 2026, zjistíte, že se vývojáři téměř výhradně přiklánějí k organizaci podle funkčnosti nebo domény, nikoliv podle technického typu souboru. To znamená, že místo složek nazvaných components, helpers a styles, kam se hází všechno napříč celou aplikací, se preferuje přístup, kdy každá funkční oblast má vlastní složku obsahující své komponenty, logiku, testy i styly na jednom místě. Tento princip se často označuje jako feature-based organizace a v praxi znatelně zrychluje orientaci v kódu, protože vývojář, který upravuje konkrétní funkci, nemusí skákat mezi desítkami vzdálených adresářů.

Uvnitř takové struktury má smysl důsledně oddělovat opakovaně použitelné komponenty od těch, které jsou vázané na konkrétní obrazovku nebo funkci. Sdílené prvky, jako jsou tlačítka, formulářová pole nebo modální okna, se obvykle soustřeďují do složky nazvané třeba shared nebo ui, zatímco specifické komponenty zůstávají uvnitř své domény. Díky tomu se předchází situaci, kdy je těžké odhadnout, zda daný soubor lze bezpečně upravit bez rizika, že se rozbije něco jinde v aplikaci.

Neméně důležitá je otázka modulů jako logických jednotek kódu, které mají jasně definované rozhraní směrem ven a skryté detaily implementace uvnitř. Moderní JavaScript pracuje s nativním systémem ES modulů, který umožňuje explicitně deklarovat, co se z daného souboru exportuje a co zůstává privátní. Právě tato jasná hranice mezi veřejným rozhraním a interní logikou je klíčová pro škálovatelnost větších projektů, protože umožňuje měnit vnitřní implementaci modulu bez obav, že se naruší chování ostatních částí aplikace, pokud se veřejné rozhraní nezmění.

Praktickým doporučením, které se v roce 2026 stále více prosazuje, je i důsledné využívání souborů typu index.js nebo index.ts jako vstupních bodů složek, díky nimž lze importovat celý modul jedním čistým příkazem, aniž by bylo nutné znát přesnou vnitřní strukturu adresáře. Tento přístup zároveň chrání interní organizaci kódu před vnějšími zásahy, protože ostatní části aplikace komunikují pouze s definovaným rozhraním.

Za zmínku stojí také oddělování logiky od prezentace, kdy se stavová a byznysová logika přesouvá do samostatných souborů, hooků nebo služeb, zatímco komponenty se soustředí čistě na vykreslování uživatelského rozhraní. Tento princip usnadňuje testování, protože logiku lze ověřovat izolovaně bez nutnosti renderovat celou komponentu.

Dobře navržená organizace modulů a komponent tak není jen estetickou záležitostí, ale má přímý dopad na rychlost vývoje, snadnost onboardingu nových členů týmu a celkovou odolnost projektu vůči budoucím změnám a rozšířením.

Konfigurační soubory v kořenovém adresáři

Když se podíváte na kořenový adresář jakéhokoliv moderního JavaScriptového projektu v roce 2026, zjistíte, že samotný zdrojový kód představuje jen menší část toho, co se tam nachází. Naprostá většina souborů v tomto adresáři má konfigurační charakter a určuje, jak se má projekt sestavit, testovat, formátovat nebo publikovat. Tyto soubory obvykle nesouvisí přímo s logikou aplikace, ale bez nich by projekt nebylo možné rozumně provozovat ani udržovat. Zatímco samotný kód psaný v JavaScriptu se typicky ukládá do složky nazvané src, lib nebo app, kořenový adresář slouží jako centrální místo, kde se soustředí veškerá metadata a nastavení celého projektu.

Nejdůležitějším souborem, který v kořenovém adresáři téměř nikdy nechybí, je package.json. Tento soubor obsahuje nejen název a verzi projektu, ale také seznam všech závislostí, skripty pro spouštění vývojového serveru, testů nebo produkčního sestavení, a řadu dalších metadat, která používají nástroje jako npm, yarn nebo pnpm. Právě z tohoto souboru se odvozuje i soubor package-lock.json nebo alternativně yarn.lock a pnpm-lock.yaml, jejichž úkolem je zajistit, že se u všech vývojářů i na produkčním serveru instalují přesně stejné verze balíčků.

Vedle správy závislostí se v kořenovém adresáři nachází i soubory určující kvalitu a konzistenci kódu. Typickým příkladem je .eslintrc nebo jeho novější varianty ve formátu JSON či JavaScriptu, které definují pravidla lintování a pomáhají odhalit potenciální chyby ještě před spuštěním aplikace. Podobnou roli hraje i .prettierrc, který stanovuje jednotný styl formátování kódu napříč celým týmem, což je v roce 2026 už standardem téměř ve všech seriózních projektech.

Pokud projekt využívá TypeScript, což je dnes běžné i u čistě JavaScriptových aplikací kvůli typové kontrole, objeví se v kořenovém adresáři i soubor tsconfig.json. Ten určuje, jak se má kód kompilovat, jaké cílové prostředí se má použít a jak se má zpracovávat typová kontrola u souborů s příponou .js nebo .jsx.

Nesmíme zapomenout ani na konfigurace sestavovacích nástrojů, jako je vite.config.js, webpack.config.js nebo rollup.config.js. Tyto soubory definují, jak se má výsledná aplikace sbalit, jaké pluginy se mají použít a jak se má optimalizovat výsledný kód pro nasazení do produkce. U testovacích frameworků se pak setkáme s konfiguračními soubory jako jest.config.js nebo vitest.config.js, které specifikují, kde se nacházejí testovací soubory a jak se má testovací prostředí nastavit.

V kořenovém adresáři se rovněž typicky objevuje soubor .gitignore, který určuje, které soubory a složky, včetně například adresáře node_modules, se nemají verzovat v Gitu, a soubor README.md, který slouží jako základní dokumentace projektu pro ostatní vývojáře.

Použití node_modules a jeho účel

Složka node_modules představuje jeden ze základních stavebních kamenů každého projektu, který využívá JavaScript a jeho rozsáhlý ekosystém knihoven. Jedná se o adresář, do kterého správce balíčků npm nebo jeho alternativy jako yarn a pnpm stahují a ukládají veškeré závislosti potřebné pro fungování aplikace. Když vývojář vytvoří nový projekt a definuje v souboru package.json, jaké knihovny bude potřebovat, právě tento adresář se stane úložištěm skutečného kódu těchto knihoven. Bez něj by aplikace nemohla načíst moduly, na kterých je postavena, a spuštění by skončilo chybou.

Praktický význam node_modules spočívá v tom, že umožňuje modulární přístup k vývoji softwaru. Místo toho, aby programátor psal veškerou funkčnost od základu, může sáhnout po hotových řešeních, která již vyřešila konkrétní problém – ať se jedná o práci s daty, komunikaci se servery, testování kódu nebo tvorbu uživatelského rozhraní. Tyto knihovny se po instalaci umístí právě do zmíněné složky a jsou odtud automaticky importovány do zdrojového kódu pomocí příkazů require nebo import, podle toho, jaký modulový systém projekt využívá.

Velikost této složky bývá často předmětem vtipů mezi vývojáři, protože i relativně jednoduchý projekt může obsahovat tisíce souborů a desítky až stovky megabajtů dat. Důvodem je skutečnost, že jednotlivé balíčky mají často vlastní závislosti, které se rovněž stahují a ukládají do vnořených adresářů. Vzniká tak rozsáhlý strom závislostí, který správce balíčků musí spravovat a udržovat v konzistentním stavu. Právě proto se tato složka nikdy nenahrává do verzovacích systémů jako Git, ale naopak se zapisuje do souboru .gitignore, aby nezatěžovala repozitář a nezpůsobovala konflikty při týmové spolupráci.

Důležitou vlastností node_modules je také to, že jeho obsah lze kdykoliv znovu vygenerovat pomocí jednoduchého příkazu, pokud má vývojář k dispozici soubor package.json a package-lock.json, který zaznamenává přesné verze všech instalovaných balíčků. Tato vlastnost zajišťuje, že projekt zůstává přenositelný a reprodukovatelný na různých strojích i v různých vývojových prostředích, aniž by bylo nutné fyzicky přenášet celou složku s závislostmi.

V roce 2026 zůstává tento přístup k organizaci závislostí standardem v komunitě JavaScriptu, přestože se objevují nástroje, které se snaží zefektivnit ukládání a sdílení modulů mezi projekty a omezit duplicitu dat na disku. I přesto se node_modules stále považuje za nezbytnou součást vývojového procesu, na kterou musí být připraven každý, kdo se s tímto jazykem a jeho nástroji začíná seznamovat.

Nástroje pro správu balíčků npm a pnpm

Když se ponoříme do struktury adresáře obsahujícího soubory napsané v JavaScriptu, jen málokdy narazíme na projekt, který by neobsahoval alespoň jeden ze dvou dominantních nástrojů pro správu balíčků – npm nebo pnpm. Oba přístupy řeší v podstatě stejný problém, tedy jak spravovat závislosti, verze knihoven a skripty potřebné k běhu aplikace, ale liší se v tom, jak s daty na disku a v souborovém systému zacházejí. Právě proto je dobré rozumět rozdílům mezi nimi, protože volba nástroje výrazně ovlivní podobu celé složky s kódem.

Klasický npm, který je součástí instalace Node.js, ukládá všechny závislosti do složky node_modules umístěné přímo v kořeni projektu. Tato složka bývá notoricky známá svou velikostí – v reálných projektech často dosahuje desítek tisíc souborů a mnoha set megabajtů dat, což zpomaluje jak instalaci, tak i běžné operace se souborovým systémem, jako je kopírování, procházení nebo indexování v editorech kódu. Npm navíc pro každý projekt vytváří vlastní kopii všech balíčků, i pokud je stejná verze knihovny používána i v jiném projektu na stejném počítači. Tím vzniká značná redundance dat, která se v součtu na disku hodně projeví, zejména u vývojářů pracujících na více projektech současně.

Naproti tomu pnpm přišel s odlišnou filozofií, která staví na centralizovaném úložišti balíčků. Všechny stažené moduly se ukládají na jedno místo v systému a do jednotlivých projektů se pak vytvářejí pouze odkazy pomocí pevných linků nebo symlinků. Výsledkem je, že složka node_modules v konkrétním projektu je výrazně menší, přesnější a instalace závislostí probíhá podstatně rychleji, protože se nemusí znovu stahovat a kopírovat balíčky, které už systém jednou zpracoval. Tento přístup je obzvláště výhodný u velkých monorepozitářů, kde se sdílí desítky nebo stovky knihoven mezi jednotlivými balíčky projektu.

Rozdíl mezi npm a pnpm se projevuje i v tom, jak striktně řeší závislosti mezi jednotlivými balíčky. Zatímco npm historicky dovoloval tzv. plochou strukturu, kde si balíček mohl teoreticky „půjčit“ závislost, kterou explicitně nedeklaroval, pnpm tento problém řeší mnohem důsledněji a nutí vývojáře specifikovat všechny závislosti přesně. To vede k méně nečekaným chybám při běhu aplikace a k větší předvídatelnosti chování kódu v produkčním prostředí.

Pro vývojáře, kteří procházejí adresářovou strukturu projektu, je tedy důležité vědět, že přítomnost souboru package-lock.json signalizuje použití npm, zatímco soubor pnpm-lock.yaml ukazuje na pnpm. Oba soubory zajišťují, že se při opětovné instalaci závislostí použijí přesně stejné verze knihoven, což je klíčové pro konzistenci mezi vývojovým, testovacím a produkčním prostředím. V roce 2026 se pnpm stále více prosazuje jako preferovaná volba zejména u větších firemních projektů a monorepozitářů, díky své efektivitě a nižší spotřebě místa na disku, přičemž npm zůstává standardní volbou díky své dostupnosti a integraci přímo do Node.js.

Bundlery a jejich výstupní adresáře

Když se dnes v roce 2026 podíváte do libovolného frontendového projektu, jen málokdy narazíte na strukturu, kde jsou zdrojové JavaScriptové soubory přímo tím, co se odesílá do prohlížeče. Mezi psaním kódu a jeho reálným nasazením stojí bundler – nástroj, který desítky až tisíce modulů poskládá do jednoho nebo několika optimalizovaných souborů. Právě proto je pochopení výstupních adresářů bundlerů klíčové pro každého, kdo se v projektu orientuje, ať už jde o vývojáře, DevOps inženýra nebo někoho, kdo se snaží zjistit, kde vlastně hledat finální kód.

Vite, který se v posledních letech stal prakticky výchozí volbou pro nové projekty, generuje svůj výstup do adresáře nazvaného dist. Tento název se stal jakýmsi neformálním standardem napříč ekosystémem – zkratka od distribution jasně signalizuje, že jde o distribuovatelnou, produkční verzi aplikace. Uvnitř najdete zpravidla hlavní HTML soubor a k němu přidružené JavaScriptové a CSS balíčky, často s hashem v názvu kvůli cachování v prohlížeči.

Webpack, dlouholetý veterán mezi bundlery, defaultně používá adresář dist také, i když u starších nebo specificky nakonfigurovaných projektů se lze setkat i s názvem build. Konfigurace ve webpack.config.js přesně určuje, kam se výstup uloží, a zkušený vývojář si tuto cestu často upravuje podle potřeb nasazení – například když projekt obsahuje více vstupních bodů nebo když se buildí pro různá prostředí zvlášť.

Nástroj Rollup, oblíbený zejména pro tvorbu knihoven a balíčků publikovaných na npm, obvykle ukládá výsledný kód do adresáře dist nebo lib. Volba mezi těmito dvěma názvy často souvisí s konvencemi konkrétního balíčku – zatímco dist naznačuje připravený, sbalený kód pro přímé použití v prohlížeči, lib se častěji objevuje u knihoven určených pro import do jiných JavaScriptových projektů přes Node.js.

Za zmínku stojí i esbuild a Parcel, které si získaly oblibu díky extrémní rychlosti buildů. Parcel typicky pracuje s adresářem dist, zatímco esbuild jako nízkoúrovňový nástroj nechává volbu výstupní cesty zcela na konfiguraci uživatele, protože sám o sobě nenutí žádnou pevnou konvenci.

Důležité je uvědomit si, že tyto vygenerované adresáře by nikdy neměly být součástí verzovacího systému jako Git. Jde o odvozený, automaticky generovaný obsah, který se dá kdykoliv znovu vytvořit spuštěním buildovacího příkazu ze zdrojových souborů. Proto se tyto složky standardně přidávají do souboru .gitignore. Pokud narazíte na projekt, kde je adresář dist nebo build omylem zahrnut ve verzovací historii, obvykle to signalizuje chybu v nastavení repozitáře, nikoliv záměr autora. Znalost těchto konvencí vám ušetří spoustu času při orientaci v cizím kódu i při ladění produkčních problémů.

Testovací soubory a jejich umístění

Testovací soubory tvoří nedílnou součást každého kvalitního JavaScript projektu, přesto se jejich organizace v praxi často podceňuje. V okamžiku, kdy se aplikace rozrůstá a přibývá modulů, komponent i pomocných funkcí, stává se otázka, kam vlastně testy umístit, mnohem důležitější, než by se na první pohled zdálo. Existují v podstatě dva hlavní přístupy, které se v komunitě vývojářů dlouhodobě prosazují, a oba mají své pro i proti.

První přístup spočívá v tom, že se testovací soubor umístí přímo do stejné složky jako testovaný kód. Pokud tedy máme soubor `utils.js`, vedle něj vznikne soubor `utils.test.js` nebo `utils.spec.js`. Tento způsob je oblíbený zejména díky své přehlednosti a rychlé orientaci — vývojář okamžitě vidí, že k danému souboru existuje odpovídající test, a nemusí složitě přecházet mezi vzdálenými částmi adresářové struktury. Nevýhodou však může být nepořádek v adresáři, kde se mísí produkční kód s testovacími skripty, což někteří týmy považují za matoucí, zejména u větších projektů s desítkami či stovkami souborů.

Druhý, stejně rozšířený přístup je vytvoření samostatné složky nazvané typicky `__tests__`, `test` nebo `tests`, která se umísťuje buď na úrovni celého projektu, nebo lokálně uvnitř jednotlivých modulů. Tento model je typický například pro projekty využívající frameworky jako Jest, Mocha nebo Vitest, kde se konvence `__tests__` stala téměř neformálním standardem. Výhodou je jasné oddělení testovací logiky od produkčního kódu, což zjednodušuje konfiguraci nástrojů pro spouštění testů i nastavení různých pravidel lintování, protože testovací soubory mohou mít odlišné požadavky na styl zápisu kódu než zbytek aplikace.

V praxi se také často setkáváme s hybridním řešením, kdy jednotkové testy (unit testy) zůstávají blízko u zdrojového kódu, zatímco integrační a end-to-end testy se soustřeďují do centralizované složky, nejčastěji nazvané `e2e` nebo `integration`. Tento model umožňuje kombinovat výhody obou přístupů — rychlou orientaci u jednotkových testů a přehlednost u komplexnějších scénářů, které často vyžadují vlastní konfigurační soubory, mockovaná data nebo speciální prostředí pro spouštění.

Důležitým faktorem při rozhodování je také to, jaký nástroj pro testování se v projektu používá. Některé nástroje, jako je Jest, testovací soubory vyhledávají automaticky podle názvu a přípony, takže umístění není striktně vynuceno, avšak většina moderních buildovacích nástrojů, včetně Vite nebo Webpacku, očekává konzistentní strukturu, aby mohla testy správně zahrnout do sledovaného rozsahu při spouštění pokrytí kódu.

V konečném důsledku by měl výběr umístění testovacích souborů vycházet z velikosti projektu, počtu členů týmu a zvyklostí, které již v organizaci existují. Pro menší projekty bývá praktičtější držet testy blízko zdrojového kódu, zatímco u rozsáhlých aplikací s mnoha vrstvami architektury se často vyplatí centralizovaná struktura, která usnadňuje správu a údržbu testovací sady jako celku.

Doporučené konvence pojmenování souborů

Při organizaci souborů v adresáři obsahujícím kód napsaný v JavaScriptu se v roce 2026 stále vyplácí držet se osvědčených konvencí, které používá naprostá většina moderních projektů. Pojmenování souborů totiž není jen estetická záležitost – přímo ovlivňuje čitelnost kódu, snadnost orientace v repozitáři a schopnost nástrojů jako ESLint, Webpack nebo Vite správně rozpoznávat moduly a jejich vzájemné vztahy.

Nejběžnější a dnes téměř univerzálně přijímanou konvencí je používání kebab-case, tedy zápisu, kde jsou slova oddělena pomlčkou a psána malými písmeny, například user-profile.js nebo fetch-data.js. Tento styl se prosadil zejména díky tomu, že je čitelný na všech operačních systémech a nezpůsobuje problémy s citlivostí na velikost písmen, která se mezi Windows, macOS a Linuxem liší. Alternativou je camelCase, kde první slovo začíná malým písmenem a další slova velkým, například userProfile.js – tento přístup se často objevuje spíše u pojmenování proměnných a funkcí v samotném kódu, nikoli u názvů souborů, přesto se s ním lze setkat i v pojmenování skriptů.

U souborů, které obsahují definici třídy nebo komponenty, zejména v ekosystému frameworků jako React, Vue nebo Angular, se často upřednostňuje PascalCase, tedy zápis, kde každé slovo začíná velkým písmenem, například UserProfile.jsx nebo Button.tsx. Tato konvence pomáhá okamžitě odlišit soubory obsahující komponenty od běžných pomocných funkcí nebo konfiguračních souborů, což zvyšuje přehlednost zejména ve větších týmových projektech.

Důležitým prvkem je také konzistentní používání přípon souborů. Zatímco běžný JavaScript kód se ukládá s příponou .js, moduly využívající syntaxi ES6 importů a exportů se někdy značí příponou .mjs, testovací soubory bývají doplněny o .test.js nebo .spec.js a soubory s typovými definicemi v TypeScriptu mají přípony .ts nebo .d.ts. Takové rozlišení umožňuje nástrojům pro sestavení a testování snadno identifikovat, jak má být konkrétní soubor zpracován.

Za zmínku stojí i konvence pro pojmenování indexových souborů, tedy souborů index.js, které slouží jako vstupní bod do daného adresáře nebo modulu. Díky tomu je možné importovat celou složku pomocí jednoduché cesty bez nutnosti specifikovat konkrétní název souboru, což zjednodušuje strukturu importů v celém projektu.

Kromě samotného stylu zápisu je vhodné dbát na to, aby název souboru výstižně popisoval jeho obsah a funkci, ideálně v angličtině, protože mezinárodní týmy a open source komunita dnes preferují jednotný jazykový standard. Vyhýbat se také doporučuje diakritice, mezerám a speciálním znakům, které mohou způsobovat problémy při práci s verzovacími systémy jako Git nebo při nasazení na různé serverové platformy. Dodržování těchto zvyklostí sice není povinné, ale výrazně usnadňuje spolupráci mezi vývojáři a dlouhodobou udržitelnost celého projektu.

Adresář plný JavaScriptových souborů je jako živý organismus – neustále se mění, roste a někdy i sám sebe přepisuje, dokud nenajdeme ten správný řád.

Bohumil Tesárek

Verzování a ignorování složek v gitu

Když pracujete na jakémkoliv JavaScriptovém projektu, dříve nebo později narazíte na otázku, co vlastně patří do verzovacího systému a co naopak ne. Git je v tomto ohledu nesmírně flexibilní nástroj, ale tato flexibilita zároveň znamená, že si musíte sami ohlídat, aby se do repozitáře nedostaly věci, které tam nemají co dělat. Typickým příkladem je složka node_modules, která u JavaScriptových projektů obsahuje veškeré nainstalované balíčky a závislosti stažené pomocí npm nebo yarn. Tato složka bývá často obrovská, může mít klidně stovky megabajtů, a co je důležitější, dá se kdykoliv znovu vygenerovat pouhým spuštěním instalačního příkazu na základě souboru package.json a package-lock.json. Z tohoto důvodu se node_modules naprosto standardně přidává do souboru .gitignore, aby ji Git při sledování změn zcela ignoroval.

Typ složky/adresáře	Typický obsah	Použití	Obvyklý název složky
Zdrojové soubory (src)	Nezkompilované .js/.jsx/.ts soubory, komponenty, moduly	Vývoj aplikace, editace kódu	src/js nebo src/scripts
Sestavené/produkční soubory (dist)	Minifikované a sloučené JS soubory pro nasazení	Nasazení na produkční server	dist nebo build
Externí knihovny	Soubory stažených knihoven a frameworků (např. jQuery, Lodash)	Sdílený kód třetích stran	node_modules nebo vendor
Testovací soubory	Unit testy a integrační testy psané v JavaScriptu	Ověřování funkčnosti kódu	test nebo __tests__
Konfigurační skripty	Soubory pro nastavení buildu, lint pravidla, webpack konfigurace	Řízení procesu vývoje a sestavení	config
Statické assets	JS soubory přímo obsluhované webovým serverem bez zpracování	Klientská logika ve statických stránkách	public/js nebo assets/js

Soubor .gitignore je vlastně obyčejný textový soubor, který se umísťuje do kořenového adresáře projektu, a do kterého se zapisují názvy souborů, přípon nebo celých složek, jež mají zůstat mimo verzovací historii. U JavaScriptových aplikací se kromě zmíněné node_modules obvykle ignorují i další adresáře vznikající při buildování projektu, například dist nebo build, kam nástroje jako Webpack, Vite nebo Rollup ukládají zkompilovaný a zoptimalizovaný výstup určený pro produkční nasazení. Tyto výstupy jsou totiž generovány automaticky ze zdrojového kódu a jejich verzování by jen zbytečně zvětšovalo repozitář a komplikovalo práci s historií projektu.

Podobně je vhodné ignorovat i dočasné soubory a cache jednotlivých nástrojů, jako je třeba .cache, .parcel-cache nebo složky vytvářené různými testovacími frameworky. Nezapomínejme ani na konfigurační soubory obsahující citlivé údaje, typicky soubor .env, kde bývají uloženy proměnné prostředí, API klíče nebo přístupové údaje k databázím. Takové informace by se do veřejného nebo i soukromého repozitáře nikdy neměly dostat, a proto je jejich ignorování v gitu doslova bezpečnostní nutností.

Na druhou stranu je klíčové verzovat samotný zdrojový kód uložený v adresářích jako src nebo components, tedy skutečné soubory s příponou .js, .jsx, .ts nebo .tsx, ve kterých se odehrává veškerá logika aplikace. Stejně tak patří do repozitáře konfigurační soubory typu package.json, tsconfig.json nebo eslintrc, protože ty definují, jak se má projekt sestavit a jak se v něm mají nainstalovat závislosti u kohokoliv, kdo si repozitář naklonuje.

Dobrou praxí je také využívat hotové šablony souboru .gitignore, které jsou volně dostupné a přizpůsobené přímo pro JavaScriptové a Node.js projekty. Tyto šablony obsahují ověřené a osvědčené výčty souborů a složek, takže vývojář nemusí přemýšlet nad každým detailem sám a riziko, že do repozitáře omylem pronikne něco nežádoucího, se výrazně snižuje.

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

Sdílené adresáře, ve kterých se hromadí soubory s příponou .js, představují v praxi mnohem větší bezpečnostní hrozbu, než by se na první pohled mohlo zdát. Ve firemním prostředí se často stává, že jedna složka slouží jako společné úložiště pro desítky až stovky vývojářů, kteří do ní nahrávají vlastní skripty, knihovny nebo pomocné moduly. Pokud přístup k takovému adresáři není důsledně řízen, vzniká prostor pro neautorizované úpravy kódu, které mohou zůstat dlouho nepovšimnuty. Stačí, aby se do sdílené složky dostal soubor s upraveným chováním, a takový kód se může dál šířit do produkčních aplikací, aniž by ho kdokoli podrobil důkladné kontrole.

Zvláštní riziko představuje takzvané dependency confusion, tedy záměna legitimního balíčku za škodlivý soubor se stejným nebo podobným názvem. Pokud se v adresáři objeví soubor, který si nástroj pro správu závislostí splete s oficiálním modulem, může dojít k načtení a spuštění cizího kódu bez vědomí vývojáře. V roce 2026 je tento typ útoku stále aktuální, protože mnoho projektů stále spoléhá na automatické stahování a slučování skriptů ze sdílených úložišť, aniž by měly zavedenou důkladnou verifikaci integrity souborů.

Dalším problémem je nedostatečná kontrola verzí. Když více lidí upravuje stejné soubory ve společné složce bez jasného systému revizí, snadno dochází k tomu, že se do finální aplikace dostane zastaralý nebo zranitelný kód, který už měl být dávno nahrazen opravenou verzí. Tato situace je obzvlášť nebezpečná u knihoven třetích stran, které se v adresáři JavaScript souborů běžně ukládají vedle vlastního kódu projektu. Pokud tyto externí soubory nikdo pravidelně needituje a nekontroluje na známé bezpečnostní chyby, stávají se snadným cílem pro útočníky, kteří cíleně vyhledávají zastaralé komponenty s veřejně známými exploity.

Velmi citlivým tématem zůstává i únik citlivých údajů přímo v kódu. Vývojáři někdy z pohodlnosti ukládají do sdílených JavaScript souborů přístupové klíče, tokeny nebo konfigurační údaje k databázím. Pokud je taková složka dostupná širšímu okruhu lidí nebo dokonce veřejně přes nesprávně nastavený server, dochází k vážnému úniku citlivých informací, který může vést k napadení celé infrastruktury. Bezpečnostní experti proto dlouhodobě doporučují oddělovat konfigurační soubory od zdrojového kódu a nikdy nevkládat citlivé hodnoty přímo do skriptů, které mohou skončit ve sdíleném prostoru.

Řešením těchto rizik je kombinace technických a organizačních opatření. Nezbytné je nastavení přísných přístupových práv, pravidelné automatizované skenování adresářů na škodlivý nebo zastaralý kód a důsledné využívání nástrojů pro kontrolu integrity balíčků. Stejně důležité je i vzdělávání vývojářů, protože i sebelepší technické zabezpečení selže, pokud lidé budou nadále sdílet citlivé údaje nedbale a bez ohledu na to, kdo všechno má k dané složce přístup.