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 na disku počítače nebo serveru, ve které jsou uloženy 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, ale ve skutečnosti struktura a organizace takového adresáře výrazně ovlivňuje, jak snadno se s projektem pracuje, jak rychle se v něm nový vývojář zorientuje a jak dobře se dá kód dlouhodobě udržovat. Když si představíte jakýkoliv webový projekt, ať už jde o jednoduchou statickou stránku nebo rozsáhlou webovou aplikaci, vždy v něm najdete alespoň jeden adresář, kde se soustřeďují právě soubory s logikou napsanou v JavaScriptu.

V praxi se takový adresář obvykle nazývá js, scripts nebo v moderních frameworcích třeba src, pokud se jedná o zdrojový kód, který se teprve před nasazením zpracovává a kompiluje. Uvnitř může být jeden soubor, ale u větších projektů se spíše setkáte s celou hierarchií podadresářů, kde jsou soubory rozdělené podle funkce, komponenty nebo modulu, ke kterému patří. Typickým příkladem je rozdělení na složky pro komponenty, pomocné funkce, konfigurační soubory, testy nebo soubory sloužící ke komunikaci se serverem přes API.

Důležité je, že adresář JavaScript souborů nemusí obsahovat jen samotný kód aplikace. Často v něm najdete i knihovny třetích stran, pokud nejsou spravovány přes balíčkovací nástroj jako npm nebo yarn, případně zkompilované a minifikované verze souborů určené přímo pro nasazení do produkčního prostředí. V takovém případě se běžně rozlišuje mezi zdrojovým adresářem, kde vývojář kód píše a upravuje, a výstupním adresářem, kam se po sestavení projektu ukládají optimalizované soubory připravené k nasazení na server.

Z pohledu organizace projektu má dobře strukturovaný adresář JavaScript souborů obrovský význam. Pokud jsou soubory rozházené bez jakéhokoliv systému, hledání konkrétní funkce nebo komponenty se stává noční můrou, zejména u rozsáhlejších aplikací s tisíci řádky kódu. Naopak přehledná struktura, kde každý soubor a složka mají jasně daný účel, umožňuje rychlou orientaci a efektivní spolupráci v týmu. Moderní vývojářské nástroje a frameworky, jako je React, Vue nebo Angular, dokonce nabízejí doporučené konvence pro strukturu adresářů, kterých se doporučuje držet, aby byl kód konzistentní napříč různými projekty a snadno pochopitelný i pro nové členy týmu.

Typická struktura složky v projektu

V typickém JavaScriptovém projektu v roce 2026 se struktura složek ustálila do podoby, kterou najdete napříč naprostou většinou moderních aplikací, ať už jde o jednoduchý frontendový web, rozsáhlou aplikaci postavenou na frameworku jako React, Vue nebo Angular, nebo backendový projekt běžící na Node.js. Kořenový adresář projektu obvykle obsahuje soubor package.json, který definuje závislosti, skripty pro spouštění a sestavování aplikace a metadata celého projektu. Vedle něj se často nachází soubor package-lock.json nebo v případě použití jiného správce balíčků třeba yarn.lock či pnpm-lock.yaml, které zajišťují konzistentní verze knihoven napříč vývojářskými prostředími.

Samotný zdrojový kód je téměř vždy umístěn ve složce nazvané src, což je zkratka pro anglické slovo „source“. Tato složka představuje srdce celé aplikace a obsahuje veškerou logiku, kterou vývojáři píší ručně. Uvnitř složky src se pak dále dělí kód podle funkčnosti a typu souborů. Časté je rozdělení na podsložky components, kde se nachází jednotlivé znovupoužitelné komponenty uživatelského rozhraní, dále utils nebo helpers, které slouží jako úložiště pomocných funkcí nevázaných na konkrétní komponentu, a také services nebo api, kde bývá umístěna logika pro komunikaci se serverem a externími rozhraními.

V projektech postavených na moderních frameworcích se navíc často objevuje složka pages nebo views, která obsahuje jednotlivé stránky či pohledy aplikace, a složka hooks, pokud projekt využívá React a jeho koncept vlastních háčků pro sdílení logiky mezi komponentami. Nezřídka se také setkáte se složkou store nebo state, kam vývojáři ukládají soubory týkající se správy globálního stavu aplikace, ať už jde o řešení jako Redux, Zustand nebo Pinia.

Mimo samotnou složku src bývá v kořenovém adresáři umístěna složka public, která obsahuje statické soubory, jako jsou obrázky, ikony, fonty nebo hlavní HTML soubor, jenž slouží jako vstupní bod aplikace v prohlížeči. Testovací soubory se pak buď nacházejí přímo vedle testovaného kódu s příponou jako .test.js nebo .spec.js, nebo jsou soustředěny do samostatné složky tests či __tests__, což usnadňuje jejich oddělení od produkčního kódu.

Nesmíme zapomenout ani na složku node_modules, která se automaticky generuje při instalaci závislostí a obsahuje veškeré externí knihovny, jež projekt využívá. Tato složka bývá kvůli své velikosti a proměnlivosti obvykle vyloučena z verzovacího systému pomocí souboru .gitignore. Právě tento soubor je dalším nezbytným prvkem každé struktury, protože určuje, které soubory a složky se nemají sledovat v rámci Gitu, což zahrnuje kromě node_modules i dočasné soubory, konfigurace lokálního prostředí nebo výstupy sestavení uložené typicky ve složce dist či build.

Rozdíl mezi src a dist adresářem

Když se ponoříte do struktury jakéhokoliv modernějšího JavaScriptového projektu, velmi rychle narazíte na dva adresáře, které na první pohled vypadají podobně, ale ve skutečnosti plní naprosto odlišnou funkci. Řeč je o složkách src a dist. Pochopení rozdílu mezi nimi je zásadní nejen pro začínající vývojáře, ale i pro ty, kteří se pohybují mezi různými projekty a potřebují se rychle zorientovat v tom, jak je kód organizován a co se s ním během vývoje vlastně děje.

Typ souboru/adresáře	Obvyklý název	Účel	Typické umístění v projektu	Běžný obsah
Zdrojový adresář	src/js nebo src/scripts	Uchování nezkompilovaného zdrojového kódu	Kořenový adresář projektu	Moduly, komponenty, funkce
Sestavovací adresář	dist nebo build	Uchování zminifikovaného a sbaleného kódu pro produkci	Generováno automaticky nástrojem (např. Webpack, Vite)	Sloučené a minifikované .js soubory
Adresář závislostí	node_modules	Uchování nainstalovaných knihoven a balíčků	Kořenový adresář projektu	Knihovny třetích stran stažené přes npm nebo yarn
Konfigurační soubory	package.json, .eslintrc, babel.config.js	Definice závislostí a nastavení projektu	Kořenový adresář projektu	Metadata projektu, pravidla lintování, transpilační nastavení
Testovací adresář	tests nebo __tests__	Uchování testovacích skriptů	Vedle src nebo uvnitř něj	Jednotkové a integrační testy psané v Jestu nebo Mocha
Veřejný adresář	public	Statické soubory dostupné přímo prohlížeči	Kořenový adresář projektu	HTML soubory, obrázky, zkompilované JS skripty
Modulární adresář	components nebo modules	Organizace opakovaně použitelného kódu	Uvnitř src	Samostatné funkční nebo UI komponenty

Adresář src, což je zkratka od anglického slova „source“, tedy zdroj, obsahuje veškerý surový, nezpracovaný kód napsaný vývojářem. Jsou zde soubory s příponou .js, .jsx, .ts nebo třeba .vue, podle toho, jaký framework nebo knihovnu projekt využívá. Tento kód je psán tak, aby byl čitelný a udržovatelný pro lidi – obsahuje komentáře, je rozdělen do menších modulů a souborů, využívá moderní syntaxi jazyka, která nemusí být podporována ve všech prohlížečích. Právě proto se tento kód nikdy nenasazuje přímo na produkční server v takové podobě, v jaké byl napsán.

Naproti tomu adresář dist, zkráceně od „distribution“, tedy distribuce, obsahuje výstupní soubory, které vznikly zpracováním kódu ze složky src pomocí různých nástrojů, jako je Webpack, Vite, Rollup nebo Babel. Tento proces se nazývá build nebo také kompilace, a jeho výsledkem je kód, který je optimalizovaný pro nasazení do reálného provozu. Soubory ve složce dist bývají minifikované, což znamená, že jsou zbaveny zbytečných mezer, komentářů a dlouhých názvů proměnných, aby zabíraly co nejméně místa a načítaly se co nejrychleji. Často se také spojují do jednoho nebo několika málo souborů namísto desítek či stovek jednotlivých modulů, což snižuje počet HTTP požadavků potřebných k načtení stránky.

Důležité je zmínit, že obsah dist adresáře se zpravidla negeneruje ručně a vývojáři by do něj neměli přímo zasahovat, protože při dalším spuštění buildovacího procesu by se veškeré manuální úpravy přepsaly. Z tohoto důvodu se také tento adresář často vůbec nenahrává do verzovacího systému, jako je Git, a bývá uveden v souboru .gitignore. Naopak složka src je srdcem celého projektu a právě zde probíhá veškerá skutečná práce na vývoji aplikace.

V praxi tak platí jednoduché pravidlo – src je pro vývojáře, dist je pro produkci. Zatímco v prvním adresáři vzniká a žije samotný kód aplikace se vším, co usnadňuje jeho psaní a údržbu, druhý adresář představuje finální, optimalizovaný balíček, který si prohlížeč nebo server skutečně stáhne a spustí. Bez pochopení tohoto rozdílu se snadno stane, že se vývojář snaží opravit chybu přímo v souborech dist, což je krok vedoucí do slepé uličky, protože při dalším buildu tyto změny zmizí.

Organizace modulů a komponent v roce 2026

V roce 2026 se organizace složek s JavaScript kódem stala mnohem promyšlenější disciplínou, než tomu bylo ještě před pár lety. Vývojáři si postupně uvědomili, že struktura adresářů není jen kosmetická záležitost, ale přímo ovlivňuje rychlost vývoje, čitelnost kódu a schopnost týmu se v projektu orientovat i po měsících od jeho vytvoření. Dnes už málokdo staví aplikaci s jedinou obří složkou plnou souborů – místo toho se prosazuje modulární přístup, kdy každá funkční část aplikace žije ve vlastním prostoru s jasně definovanými hranicemi.

Nejrozšířenějším přístupem zůstává organizace podle funkčnosti (tzv. feature-based struktura), kdy se soubory nesdružují podle typu (komponenty, styly, testy), ale podle toho, k čemu ve výsledku slouží. To znamená, že veškerá logika týkající se například přihlašování uživatele – komponenty, pomocné funkce, testy i typy – leží pohromadě v jedné složce s názvem něco jako auth nebo login. Tento princip výrazně zjednodušuje orientaci v rozsáhlejších projektech, protože pokud potřebujete upravit konkrétní funkci, nemusíte skákat mezi desítkami vzdálených adresářů.

Vedle toho se v roce 2026 běžně kombinuje domain-driven organizace s atomárním designem, zejména u projektů postavených na frameworcích jako React, Vue nebo Svelte. Komponenty se dělí na drobné stavební prvky (atoms), složitější celky (molecules) a hotové obrazovky nebo sekce (organisms), přičemž tato hierarchie se promítá přímo do struktury složek. Díky tomu je možné rychle rozeznat, zda se jedná o znovupoužitelný prvek určený pro celou aplikaci, nebo o něco specifického pouze pro jednu konkrétní obrazovku.

Velkou roli hraje také rozdělení na sdílené (shared) a doménové (domain) vrstvy. Sdílené složky obsahují univerzální nástroje, utility funkce, konstanty nebo generické komponenty, které se používají napříč celým projektem. Doménové složky naopak obsahují vše, co patří k jedné konkrétní části byznysové logiky. Toto oddělení pomáhá udržet kód čistý a zabraňuje vzniku chaotických závislostí mezi jednotlivými částmi aplikace.

Nezanedbatelnou roli hraje i konvence pojmenování souborů a složek, která v roce 2026 čím dál více směřuje ke konzistenci napříč celým týmem díky automatizovaným nástrojům pro lintování a formátování. Struktura index souborů, které slouží jako veřejné rozhraní modulu, se stala standardem – umožňuje totiž skrýt vnitřní implementaci a exportovat pouze to, co má být skutečně dostupné zvenčí. Tím se výrazně snižuje riziko, že si jiný vývojář omylem naimportuje interní pomocnou funkci, která nebyla určena k veřejnému použití.

Nelze opomenout ani vliv monorepo architektury, která se v posledních letech stala běžnou praxí zejména u větších firem a projektů s více aplikacemi sdílejícími společný kód. Nástroje jako Nx nebo Turborepo umožňují organizovat desítky balíčků a aplikací v jednom repozitáři, přičemž každá složka představuje samostatně publikovatelný nebo testovatelný celek. Tento přístup šetří čas při údržbě a usnadňuje sdílení komponent mezi projekty, aniž by bylo nutné duplikovat kód nebo řešit složitou synchronizaci mezi oddělenými repozitáři.

Konvence pojmenování souborů a složek

Při organizaci JavaScriptových projektů se pojmenování souborů a složek často podceňuje, přestože jde o jeden z faktorů, který nejvíce ovlivňuje čitelnost a udržovatelnost kódu v dlouhodobém horizontu. Vývojáři, kteří k tomuto tématu přistupují nahodile, se dříve nebo později dostanou do situace, kdy je repozitář prakticky nečitelný a orientace v něm zabere víc času než samotné psaní kódu.

V praxi se v roce 2026 nejčastěji setkáváme se dvěma přístupy k pojmenování souborů – camelCase a kebab-case. Zatímco camelCase byl historicky spjatý především s pojmenováním proměnných a funkcí přímo v kódu, kebab-case se stal standardem pro názvy souborů, zejména v moderních frameworcích jako React, Vue nebo Angular. Důvod je prozaický – mnoho operačních systémů a nástrojů rozlišuje velká a malá písmena nekonzistentně, takže soubor pojmenovaný pomocí pomlček je bezpečnější volbou a předchází chybám při přesunu projektu mezi Windows, macOS a Linuxem.

U komponent v Reactu se často objevuje výjimka v podobě PascalCase, kdy název souboru odpovídá názvu exportované komponenty, například Button.jsx nebo UserProfileCard.jsx. Tento přístup usnadňuje okamžitou identifikaci, co soubor obsahuje, aniž by bylo nutné jej otevírat. Naopak pomocné funkce, konfigurační soubory nebo utility bývají pojmenovány spíše popisně a v kebab-case, například format-date.js nebo api-client.js.

Co se týče složek a adresářové struktury, klíčovým principem zůstává logické seskupování podle funkčnosti, nikoliv podle typu souboru. Tedy raději složka „user-profile“ obsahující komponentu, styly i testy, než oddělené složky „components“, „styles“ a „tests“, kde jsou soubory patřící k sobě rozeseté po celém projektu. Tento přístup, často označovaný jako feature-based struktura, se v roce 2026 stal prakticky standardem u větších aplikací postavených na Reactu, Vue nebo Next.js.

Důležitou roli hraje také konzistence v rámci celého týmu. Pokud si vývojáři na začátku projektu nedomluví jasná pravidla, dochází k situaci, kdy jeden člen týmu používá camelCase, druhý snake_case a třetí kombinuje oba přístupy podle nálady. Výsledkem je zmatek, který komplikuje code review i onboarding nových kolegů. Proto se doporučuje sepsat jednoduchý styleguide, případně využít automatizované nástroje jako ESLint nebo ESLint pluginy zaměřené přímo na kontrolu názvů souborů.

Nezanedbatelný je i vliv na verzovací systémy. Git je citlivý na velikost písmen, a pokud se v týmu pracuje na různých operačních systémech, nekonzistentní pojmenování může způsobit duplicitní soubory nebo konflikty, které jsou obtížně dohledatelné. Z tohoto důvodu se doporučuje vyhýbat se mezerám, diakritice a speciálním znakům v názvech, a to jak u souborů, tak u složek, bez ohledu na to, zda se jedná o frontendový nebo backendový JavaScriptový projekt.

Použití v moderních frameworcích jako React

V roce 2026 už je téměř nemyslitelné pracovat s frameworkem React bez toho, aby projekt měl důkladně promyšlenou strukturu složek pro soubory napsané v JavaScriptu, případně v jeho nástavbě TypeScript, která se v produkčním prostředí prosadila jako standard. Když se podíváme na typický React projekt vytvořený pomocí nástrojů jako Vite, který dnes prakticky nahradil starší Create React App, zjistíme, že organizace adresářové struktury přímo ovlivňuje čitelnost, udržovatelnost a rychlost vývoje celé aplikace. Vývojáři si postupem let vytvořili několik osvědčených přístupů, jak složky s JavaScriptovým kódem členit, a každý z nich má svá specifika i důvody, proč se v konkrétních situacích používá.

Nejrozšířenějším přístupem je takzvaná feature-based struktura, kdy se soubory neorganizují podle typu (tedy zvlášť komponenty, zvlášť stavy, zvlášť pomocné funkce), ale podle funkčních celků aplikace. To znamená, že složka nazvaná například `features/authentication` obsahuje veškerý JavaScriptový kód potřebný pro přihlašování uživatele – komponenty, testy, validační logiku i volání API. Tento způsob organizace se v roce 2026 stal prakticky výchozím doporučením pro střední a větší aplikace, protože umožňuje týmu pracovat na jednotlivých funkcích nezávisle a minimalizuje riziko konfliktů při verzování.

Vedle toho stále přežívá i klasičtější přístup, kdy se v kořenovém adresáři `src` vytvářejí složky jako `components`, `hooks`, `utils`, `context` nebo `services`. Tato struktura je oblíbená především u menších projektů nebo u vývojářů, kteří teprve s Reactem začínají, protože je intuitivní a snadno pochopitelná. Složka `components` typicky obsahuje znovupoužitelné JavaScriptové soubory reprezentující jednotlivé UI prvky, zatímco `hooks` sdružuje vlastní React hooky psané opět v čistém JavaScriptu nebo TypeScriptu. Právě oddělení logiky do vlastních hooků je jedním z klíčových vzorů, které moderní React aplikace v roce 2026 hojně využívají, protože umožňuje sdílet stavovou logiku mezi komponentami bez nutnosti duplikovat kód.

Důležitou roli hraje také způsob, jakým se v rámci složek řeší import a export modulů. Díky ES modulům, které jsou dnes plně podporovány všemi moderními prohlížeči i bundlery, mohou vývojáři v každé složce vytvářet takzvané barrel soubory (obvykle pojmenované `index.js` nebo `index.ts`), jež zpřehledňují importy z jiných částí aplikace. Tento přístup sice zjednodušuje práci, ale je potřeba s ním zacházet opatrně, protože při špatném použití může negativně ovlivnit výkon bundleru a zpomalit takzvané tree-shaking, tedy odstraňování nepoužívaného kódu při sestavování produkční verze aplikace.

Nelze opomenout ani rostoucí význam monorepo architektur, kde jedna složka obsahuje více souvisejících JavaScriptových projektů najednou, typicky spravovaných nástroji jako Turborepo nebo Nx. V roce 2026 tento přístup využívají zejména větší firmy, které potřebují sdílet komponenty a logiku mezi více aplikacemi postavenými na Reactu, přičemž jasně definovaná adresářová struktura je zde naprosto zásadní pro udržení přehlednosti celého kódu.

Role souboru package.json a závislostí

Každý adresář obsahující JavaScriptový kód se dříve nebo později setká se souborem package.json, který funguje jako jeho rodný list a zároveň jako mapa celého projektu. Tento na první pohled nenápadný textový soubor ve formátu JSON nese informace o tom, jak se projekt jmenuje, jakou má verzi, kdo je jeho autorem, jakou licenci používá, a především jaké další knihovny a nástroje potřebuje ke svému běhu. Bez něj by se moderní JavaScriptový projekt jen těžko orientoval sám v sobě, protože právě tento soubor definuje pravidla hry pro celý adresář kódu.

Když si otevřete typickou složku s JavaScriptovým projektem, package.json obvykle najdete přímo v jejím kořeni. Odtud se odvíjí veškerá struktura – podadresáře jako node_modules, src nebo dist na něj referují nebo z něj vycházejí. Nejdůležitější částí souboru jsou bezesporu sekce dependencies a devDependencies, které obsahují seznam všech externích balíčků, na kterých projekt stojí. Dependencies zahrnují knihovny nezbytné pro běh aplikace v produkčním prostředí, zatímco devDependencies obsahují nástroje potřebné jen během vývoje, například testovací frameworky, linter nebo bundler.

Tyto závislosti se instalují pomocí správců balíčků, mezi něž patří především npm, yarn nebo modernější pnpm. Po zadání instalačního příkazu se všechny uvedené knihovny stáhnou z centrálního registru a uloží do složky node_modules, která bývá součástí struktury projektu, ačkoliv se běžně nenahrává do verzovacích systémů díky svému obrovskému objemu dat. Právě proto se v adresáři téměř vždy objevuje i soubor .gitignore, který node_modules vylučuje z verzování, protože veškeré potřebné informace pro jejich znovuvytvoření jsou už obsaženy v package.json a přidruženém souboru package-lock.json nebo yarn.lock.

Tyto zámkové soubory hrají v roce 2026 stále klíčovou roli, protože zajišťují, že se u všech vývojářů i na produkčních serverech instalují přesně stejné verze závislostí, což předchází nepříjemným situacím, kdy kód funguje na jednom počítači, ale jinde selhává kvůli drobné odlišnosti ve verzi nějaké knihovny. Tento princip reprodukovatelnosti sestavení je dnes považován za základní standard profesionálního vývoje.

Kromě závislostí obsahuje package.json také sekci scripts, kde si vývojáři definují vlastní příkazy pro spuštění testů, sestavení produkční verze nebo start vývojového serveru. Tyto skripty se pak volají jednoduchými zkratkami přímo z terminálu, což výrazně zjednodušuje práci s celým adresářem kódu a odstraňuje nutnost pamatovat si dlouhé a složité příkazy.

Struktura složky s JavaScriptovým kódem tak vlastně kopíruje logiku, kterou package.json nastavuje – zdrojové soubory bývají oddělené od konfiguračních, testy mají svůj vlastní prostor a závislosti jsou centrálně řízeny jediným místem, díky čemuž se i rozsáhlé projekty udrží přehledné a snadno spravovatelné napříč celým týmem vývojářů.

Bundlery a jejich vliv na strukturu

Struktura složek s JavaScriptem se v posledních letech vyvíjí především pod tlakem nástrojů, které se starají o sestavení výsledné aplikace. Bundlery jako Webpack, Vite, esbuild nebo Rollup zásadně ovlivňují to, jak si programátoři organizují zdrojové soubory, a čím dál častěji diktují i konvence, které se pak stávají fakticky standardem v celém projektu. Zatímco dříve se soubory JavaScriptu skládaly ručně pomocí tagů script a jejich pořadí v HTML dokumentu, dnes je téměř nemyslitelné pracovat na větším projektu bez toho, aby existoval jeden vstupní bod, ze kterého bundler celou závislostní strukturu poskládá.

Právě existence vstupního bodu, obvykle nazvaného index.js nebo main.js, vede k tomu, že se ostatní soubory přirozeně organizují kolem něj. Bundlery totiž procházejí celý strom importů a vytvářejí z něj grafovou reprezentaci závislostí, takže je logické, že se moduly ukládají do adresářů podle toho, jak spolu souvisí, nikoli podle toho, kdy vznikly nebo kdo je napsal. Díky tomu se v praxi prosadilo dělení na složky jako components, utils, services, hooks nebo store, přičemž toto členění vychází právě z potřeby bundleru snadno dohledat a spojit všechny soubory do jednoho nebo více výsledných balíčků.

Velký vliv na strukturu má také code splitting, tedy technika, kdy bundler rozděluje výsledný kód do menších částí, které se načítají až ve chvíli, kdy je uživatel skutečně potřebuje. To vede k tomu, že se v projektech objevují složky organizované podle jednotlivých stránek nebo funkčních celků, protože právě takové dělení umožňuje efektivní lazy loading. Pokud je struktura souborů rozdrobená a nelogická, bundler nemůže optimálně určit, které části kódu patří k sobě, a výsledná aplikace pak trpí zbytečně velkými balíčky nebo naopak přílišnou fragmentací.

Nástroje jako Vite navíc svým přístupem, který během vývoje nepoužívá tradiční bundling, ale pracuje s nativními ES moduly přímo v prohlížeči, přispěly k tomu, že se stále více projektů drží přísně modulární struktury, kde každý soubor exportuje jen jednu jasně definovanou funkčnost. To zpětně podporuje čistotu adresářové struktury, protože nepřehledné a příliš propletené závislosti výkon bundleru citelně zpomalují.

Nezanedbatelnou roli hrají i konfigurační soubory bundlerů, tedy webpack.config.js, vite.config.js a podobné, které se obvykle umísťují do kořenového adresáře projektu. Tyto soubory často obsahují aliasy pro cesty, díky nimž se v kódu nemusí psát dlouhé relativní cesty typu ../../../components, ale stačí kratší zápis jako @components. Tento zvyk zpětně ovlivňuje i to, jak hluboko se vývojáři odvažují zanořovat složky, protože s aliasy přestává být hloubka adresářové struktury takovým problémem jako dříve.

Celkově lze říct, že bundlery nejsou jen technickým doplňkem, ale aktivně formují způsob, jakým se JavaScriptové projekty v roce 2026 organizují, a jejich vliv na strukturu složek je patrný v naprosté většině moderních aplikací.

Ve složce plné JavaScriptu se skrývá celý vesmír – soubory na sebe odkazují, funkce volají jiné funkce, a než se nadějete, jediný řádek kódu rozhoduje o tom, zda se celá aplikace zhroutí, nebo ožije.

Bohumil Vrána

Testovací soubory a jejich umístění

Testovací soubory tvoří v každém JavaScriptovém projektu specifickou kategorii, která si zaslouží promyšlené umístění ve struktuře adresářů. Existuje v podstatě několik zavedených přístupů, přičemž ani jeden z nich není univerzálně správný – vždy záleží na velikosti projektu, preferencích týmu a použitém testovacím frameworku.

Prvním rozšířeným způsobem je umístění testů přímo vedle testovaného souboru, tedy v tzv. co-location přístupu. Pokud máte soubor userService.js, testovací soubor se pak jmenuje typicky userService.test.js nebo userService.spec.js a leží ve stejné složce. Tento způsob má výhodu v tom, že je okamžitě jasné, který test patří ke kterému kódu, a při refaktoringu nebo mazání souboru si vývojář snadno všimne, že je potřeba upravit i test. Nevýhodou může být přeplněnost adresářů, zejména u větších modulů s desítkami souborů.

Druhým velmi oblíbeným řešením je vytvoření samostatné složky nazvané __tests__, která se umísťuje buď na úrovni celého projektu, nebo lokálně uvnitř jednotlivých modulů. Tento přístup preferují například vývojáři pracující s frameworkem Jest, kde je konvence __tests__ automaticky rozpoznávána bez nutnosti další konfigurace. Díky tomu zůstává hlavní zdrojový kód přehledný a testy jsou logicky oddělené, přičemž si zachovávají jasnou vazbu na testovaný modul díky shodné adresářové struktuře.

Třetí variantou, kterou volí zejména větší a komplexnější projekty, je úplné oddělení testovací a zdrojové části do dvou paralelních větví adresářového stromu – typicky src pro produkční kód a test nebo tests na stejné úrovni jako src. Uvnitř složky tests se pak struktura podadresářů většinou zrcadlí podle struktury ve src, takže test pro soubor src/utils/formatDate.js najdeme na cestě tests/utils/formatDate.test.js. Tento přístup se hodí zejména tam, kde se testy dělí podle typu – jednotkové testy, integrační testy a end-to-end testy bývají v samostatných podsložkách, například tests/unit, tests/integration a tests/e2e.

Při rozhodování, kam testy umístit, je také důležité zohlednit konfiguraci nástrojů jako Jest, Vitest, Mocha nebo Cypress, protože každý z nich má vlastní výchozí vzory pro vyhledávání testovacích souborů. Většina moderních nástrojů umožňuje tyto vzory přizpůsobit v konfiguračním souboru, takže tým si může zvolit vlastní konvenci a udržet ji konzistentní napříč celým projektem. Klíčové je zejména to, aby zvolený způsob organizace zůstal jednotný a aby noví členové týmu měli okamžitě jasno, kde testy hledat a kam je při psaní nového kódu doplňovat.

Bezpečnost a správa citlivých skriptů

Ve složce nebo adresáři, kde jsou uloženy soubory kódu napsaného v JavaScriptu, se často skrývá mnohem víc, než by se na první pohled zdálo. Nejde jen o funkce, proměnné a logiku aplikace – v praxi se do těchto adresářů běžně dostávají i citlivé údaje, které by tam vůbec neměly být. Typickým příkladem jsou přístupové klíče k API, přihlašovací tokeny, hesla k databázím nebo konfigurační soubory obsahující interní adresy serverů. Pokud programátor takové informace omylem zapíše přímo do zdrojového kódu a následně je nahraje do veřejného repozitáře, riziko zneužití roste prakticky okamžitě, protože internet je plný automatizovaných nástrojů, které neustále prohledávají veřejné úložiště kódu právě kvůli podobným chybám.

Z tohoto důvodu je nezbytné věnovat organizaci a zabezpečení adresářové struktury projektu mimořádnou pozornost. Osvědčeným postupem je oddělovat citlivé konfigurační údaje od samotné logiky aplikace, a to pomocí proměnných prostředí nebo speciálních konfiguračních souborů, které se do verzovacího systému nikdy nenahrávají. K tomu slouží soubor s příponou .gitignore, jenž definuje, které soubory a složky má systém pro správu verzí ignorovat. Bez správně nastaveného .gitignore se stává, že vývojář nevědomky zveřejní obsah, který měl zůstat čistě lokální, a to i v případě, že jde jen o testovací nebo vývojové prostředí.

Dalším důležitým aspektem je pravidelná kontrola závislostí, tedy externích knihoven a balíčků, které se v JavaScriptových projektech instalují prostřednictvím správců balíčků. Tyto knihovny se ukládají do specifických adresářů v rámci projektu a jejich objem bývá často mnohonásobně větší než samotný autorský kód. Právě zde se skrývá riziko, protože ne všechny knihovny jsou udržované, aktualizované nebo prověřené z hlediska bezpečnosti. Zastaralé nebo zranitelné závislosti patří mezi nejčastější příčiny bezpečnostních incidentů ve webových aplikacích, a proto je vhodné pravidelně spouštět nástroje pro audit závislostí, které dokážou odhalit známé zranitelnosti dříve, než se stanou skutečným problémem.

Neméně podstatná je i otázka přístupových práv k samotným souborům a složkám na serveru nebo v cloudovém úložišti. Pokud je adresář s kódem dostupný širšímu okruhu lidí, než je nezbytně nutné, zvyšuje se pravděpodobnost neoprávněného zásahu, ať už úmyslného nebo náhodného. Doporučuje se proto důsledně nastavovat role a oprávnění, využívat vícefaktorové ověřování pro přístup ke sdíleným repozitářům a pravidelně kontrolovat historii změn, aby bylo možné rychle odhalit podezřelou aktivitu. V neposlední řadě je vhodné zavést i proces pravidelného zálohování, protože i dobře zabezpečený projekt může být zasažen chybou lidského faktoru nebo technickým selháním, a mít funkční zálohu se v takové chvíli stává klíčovým prvkem ochrany celého projektu.

Nástroje pro automatické formátování kódu

Když se podíváte do jakékoli složky nebo adresáře souborů kódu napsaných v jazyce JavaScript, který prošel rukama více vývojářů, velmi rychle zjistíte, proč je automatické formátování téměř nutností. Každý programátor má tendenci psát kód trochu jinak – jiné odsazení, jiné umístění složených závorek, jiné preference ohledně uvozovek nebo středníků. Bez jednotného přístupu se z projektu stává změť stylů, kde se obtížně orientuje a kde se v historii verzí objevují zbytečné rozdíly způsobené jen kosmetickými úpravami. Právě proto se do vývojářského pracovního postupu zařazují nástroje, které formátování řeší automaticky a bez nutnosti nad tím přemýšlet.

Nejrozšířenějším řešením zůstává Prettier, který se v roce 2026 stále drží jako neformální standard napříč projekty psanými v JavaScriptu i příbuzných jazycích jako TypeScript. Jeho filozofie je jednoduchá – vývojář nemá řešit, jak má kód vypadat, protože o to se postará nástroj sám podle předem daných pravidel. Prettier dokáže projít celou složku se soubory, sjednotit odsazení, délku řádků, styl uvozovek i používání středníků, a to konzistentně napříč stovkami souborů během několika sekund. Velkou výhodou je také těsná integrace s editory jako Visual Studio Code, kde lze nastavit formátování při každém uložení souboru, takže se nekonzistence do repozitáře prakticky nedostane.

Vedle Prettieru hraje důležitou roli i ESLint, který sice primárně slouží k odhalování chyb a problematických konstrukcí v kódu, ale díky pluginům dokáže zároveň vynucovat i formátovací pravidla. V praxi se často kombinuje právě s Prettierem tak, že ESLint hlídá kvalitu a logiku kódu, zatímco Prettier se stará čistě o vizuální podobu. Tato kombinace se v adresářích JavaScriptových projektů objevuje snad nejčastěji ze všech možných řešení a bývá součástí konfiguračních souborů, které se sdílejí napříč celým týmem, aby každý měl při psaní kódu stejná pravidla.

Kromě těchto dvou nástrojů se stále používá i StandardJS, tedy sada pravidel, která eliminuje nutnost jakékoli vlastní konfigurace – vývojář prostě přijme daný styl bez diskuzí o tom, kde má být mezera nebo jak dlouhý smí být řádek. Pro projekty, kde se klade důraz na rychlost nastavení a minimální údržbu, je to atraktivní volba, i když menší flexibilita může některým týmům nevyhovovat.

Nezanedbatelnou roli hrají i integrace do systémů pro správu verzí, kdy se formátování spouští automaticky před každým commitem pomocí nástrojů jako Husky v kombinaci s lint-staged. Díky tomu se do sdíleného repozitáře nikdy nedostane soubor, který by neodpovídal dohodnutému stylu, a celá složka projektu tak zůstává přehledná, čitelná a udržovatelná i při práci desítek lidí najednou.

Doporučené postupy pro škálovatelné projekty

Struktura složky s JavaScriptovými soubory rozhoduje o tom, zda se v projektu za rok vyznáte, nebo zda se z něj stane bezedná studna zmatku. V roce 2026 už prakticky žádný seriózní tým nezačíná psát kód bez toho, aby si předem rozvrhl, kam který soubor patří a proč. Základním pravidlem je oddělení podle zodpovědnosti, nikoliv podle typu souboru. Místo toho, aby se všechny komponenty házely do jedné složky components a všechny funkce do utils, se osvědčuje dělení podle domén nebo funkčních celků – tedy podle toho, co daná část aplikace skutečně dělá, ne podle toho, jak vypadá.

U větších projektů se vyplácí přemýšlet nad strukturou jako nad mapou, po které se bude pohybovat nejen autor kódu, ale i kolegové, kteří přijdou o rok později a nebudou mít tušení, proč je něco umístěno zrovna tam, kde je. Konzistence pojmenování souborů a složek je proto naprosto klíčová – pokud se jednou zvolí camelCase pro názvy souborů, musí se dodržovat všude, jinak vzniká chaos, který zpomaluje orientaci a zvyšuje riziko chyb při importech.

Škálovatelnost se dále opírá o jasné oddělení logiky od prezentace. Soubory obsahující čistou obchodní logiku by neměly být promíchány s těmi, které se starají o vykreslování rozhraní. Tento přístup usnadňuje testování, protože logiku lze ověřovat izolovaně, bez závislosti na uživatelském rozhraní. V roce 2026 je běžnou praxí i důsledné využívání barrel souborů, tedy centrálních `index.js` souborů, které zpřehledňují importy a snižují počet dlouhých a matoucích cest napříč projektem.

Neméně důležité je myslet na budoucí růst projektu už od začátku. Struktura, která funguje pro deset souborů, nemusí fungovat pro tisíc, a přepisovat celou organizaci projektu v polovině vývoje je vždy bolestivé a časově nákladné. Proto se doporučuje od počátku počítat s modulárním přístupem, kde každá funkční část aplikace tvoří svůj vlastní uzavřený celek se všemi potřebnými soubory pohromadě – komponentou, styly, testy i případnými pomocnými funkcemi.

Dokumentace uvnitř složek, byť jen ve formě krátkých komentářů nebo README souborů u složitějších modulů, se také ukazuje jako investice, která se vrátí. Nový člen týmu se tak dokáže zorientovat mnohem rychleji, než kdyby musel procházet každý soubor zvlášť a domýšlet si souvislosti. Stejně tak je vhodné mít jasně definovaná pravidla pro to, kam patří konfigurační soubory, testy nebo pomocné skripty, aby nedocházelo k jejich rozptýlení po celém projektu.

Nakonec je třeba zmínit i důležitost automatizovaných nástrojů, které pomáhají hlídat dodržování zvolené struktury – lintery a formátovací nástroje dnes dokážou upozornit i na nevhodné umístění souborů nebo nesprávné importy. Díky tomu se dá udržet pořádek i ve velkých týmech, kde by jinak bylo téměř nemožné hlídat konzistenci ručně. Dobře navržená složková struktura tak není jen estetickou záležitostí, ale reálně ovlivňuje rychlost vývoje, počet chyb a celkovou udržitelnost projektu v dlouhodobém horizontu.