Jak si v roce 2026 udržet pořádek ve složce s JavaScriptem

Co je adresář se soubory JavaScriptu

Adresář se soubory JavaScriptu je v podstatě obyčejná složka v souborovém systému počítače nebo webového projektu, do které jsou uloženy soubory s koncovkou .js, případně i další soubory přímo související s během a organizací JavaScriptového kódu, jako jsou moduly, konfigurační soubory nebo pomocné knihovny. Na první pohled se může zdát, že jde o naprosto triviální věc, ale skutečnost je taková, že způsob, jakým jsou tyto adresáře strukturovány, výrazně ovlivňuje čitelnost, udržovatelnost a rozšiřitelnost celého projektu. Vývojáři si postupem let vytvořili řadu konvencí, které pomáhají orientovat se v rozsáhlých aplikacích, a právě organizace souborů JavaScriptu do logických adresářů je jednou z nich.

V praxi se často setkáváme s tím, že hlavní adresář projektu obsahuje podadresář nazvaný například src, js nebo scripts, ve kterém jsou soustředěny veškeré zdrojové soubory psané v JavaScriptu. Uvnitř tohoto adresáře pak bývá dále členěno podle funkčnosti – najdeme zde třeba složky pro komponenty, služby, utility, konfigurace nebo testy. Toto členění není náhodné, ale vychází z potřeby oddělit jednotlivé části aplikace tak, aby bylo možné se v kódu snadno orientovat i po delší době, kdy si na projekt vývojář nevzpomíná do detailu. Dobře uspořádaný adresář se soubory JavaScriptu tak funguje jako mapa celého projektu.

Důležité je zmínit, že adresář se soubory JavaScriptu nemusí obsahovat pouze samotný zdrojový kód aplikace. Často se v něm nachází i závislosti, tedy externí knihovny a balíčky, které jsou stahovány pomocí správců balíčků, jako je npm nebo yarn. Tyto závislosti bývají uloženy v samostatném adresáři, typicky nazvaném node_modules, který je od zbytku projektu oddělen právě proto, aby nedocházelo k míchání vlastního kódu s kódem třetích stran. Toto oddělení je klíčové pro přehlednost a také pro správu verzí, protože obsah adresáře node_modules se běžně neverzuje pomocí nástrojů jako Git.

V roce 2026 je situace kolem organizace JavaScriptových adresářů ovlivněna především moderními nástroji pro sestavování aplikací a frameworky, které mají své vlastní zavedené konvence. Aplikace postavené na frameworcích, jako je React, Vue nebo Angular, mají typicky předdefinovanou strukturu adresářů, kterou generují automatizované nástroje při vytváření nového projektu. Díky tomu se vývojáři nemusí zabývat tím, jak adresář se soubory JavaScriptu navrhnout od nuly, ale mohou se spolehnout na osvědčené vzory, které usnadňují spolupráci v týmu i pozdější škálování projektu.

Nelze také opomenout, že správně navržený adresář se soubory JavaScriptu má vliv na výkon a rychlost sestavování aplikace, protože moderní nástroje pro bundling dokáží efektivněji analyzovat a zpracovávat kód, pokud je logicky rozdělen a nejsou v něm zbytečné duplicity nebo chaoticky rozmístěné soubory. Z tohoto důvodu je promyšlená organizace adresářů považována za jeden ze základních pilířů kvalitního softwarového vývoje v JavaScriptu.

Typická struktura složky projektu v roce 2026

V roce 2026 vypadá typický projekt psaný v JavaScriptu na první pohled možná podobně jako před pár lety, ale pod povrchem se toho změnilo podstatně víc, než by člověk čekal. Kořenový adresář dnes obvykle obsahuje soubor package.json, který zůstává centrálním bodem celého projektu – definuje závislosti, skripty pro build, testování i nasazení, a čím dál častěji také konfiguraci pro nástroje jako ESLint nebo Prettier přímo ve svém obsahu, aby se snížil počet samostatných konfiguračních souborů rozesetých po kořeni. Vedle něj se objevuje package-lock.json nebo alternativně soubory od pnpm či Yarn, podle toho, jaký správce balíčků tým zvolil. Právě volba mezi npm, pnpm a Yarn je v roce 2026 stále aktuální téma, přičemž pnpm si získal značnou oblíbenost díky efektivnímu ukládání závislostí a rychlosti instalace u větších monorepo projektů.

Samotný zdrojový kód se téměř vždy nachází ve složce nazvané src, která je srdcem celé aplikace. Uvnitř této složky je struktura silně závislá na typu projektu – u frontendových aplikací postavených na Reactu, Vue nebo Svelte se často setkáváme s dělením podle komponent, kde každá komponenta má svou vlastní podsložku obsahující logiku, styly a případně testy. Tento přístup, někdy označovaný jako feature-based struktura, se v posledních letech prosadil na úkor staršího dělení podle typu souboru, protože usnadňuje škálování a údržbu rozsáhlejších aplikací.

Nechybí ani složka components, hooks, utils nebo services, přičemž právě složka services bývá místem, kde se soustředí veškerá komunikace s backendem, ať už prostřednictvím REST API nebo GraphQL. Konfigurace pro sestavení projektu je dnes nejčastěji řešena pomocí Vite, který v roce 2026 prakticky nahradil starší nástroje jako Webpack u nových projektů, díky své rychlosti a jednoduchosti nastavení. Proto se v kořenovém adresáři běžně objevuje soubor vite.config.js nebo jeho varianta v TypeScriptu.

Typová bezpečnost se stala standardem, a proto naprostá většina moderních projektů obsahuje soubor tsconfig.json, i pokud je většina kódu psána v čistém JavaScriptu s postupným přechodem na TypeScript. Testovací soubory se obvykle nacházejí přímo vedle testovaného kódu s koncovkou .test.js nebo v samostatné složce tests, přičemž Vitest se stal preferovaným nástrojem pro testování díky své rychlosti a kompatibilitě s Vite.

Nesmí chybět ani složka public pro statické soubory, konfigurace pro CI/CD ve skryté složce .github a soubor .env pro proměnné prostředí, který se z bezpečnostních důvodů nikdy nenahrává do verzovacího systému. Celá struktura tak odráží důraz na modularitu, přehlednost a snadnou spolupráci v týmu.

Složka JavaScriptu je jako tichá dílna, kde se ve stínu ukrývají stovky souborů, každý s vlastním příběhem, čekajícím na chvíli, kdy prohlížeč vdechne jejich kódu život.

Bohumil Krejčí

Rozdíl mezi src, dist a build

Když se ponoříme do struktury typického JavaScriptového projektu, narazíme na tři adresáře, které se často pletou i zkušeným vývojářům, kteří s daným frameworkem nebo build systémem začínají poprvé – jsou to src, dist a build. Každá z těchto složek má naprosto odlišný účel a pochopení jejich role je zásadní pro orientaci v projektu i pro efektivní práci s verzovacím systémem.

Složka src (zkratka od slova source, tedy zdroj) obsahuje samotný zdrojový kód psaný vývojářem. Jsou zde soubory s příponou .js, .jsx, .ts, .vue nebo podobné, které nejsou určeny k přímému nasazení do produkčního prostředí. Tento kód je psán v moderní syntaxi, může obsahovat importy modulů, komentáře, nevyužité proměnné pro účely testování a další prvky, které jsou pro vývojáře užitečné, ale pro koncového uživatele zbytečné nebo dokonce nežádoucí. Právě obsah složky src se verzuje v Gitu a je to místo, kam vývojáři soustavně zasahují při psaní nových funkcí nebo oprav chyb.

Naproti tomu dist (od slova distribution) představuje výstupní složku, která obsahuje zkompilovaný a optimalizovaný kód připravený k distribuci – ať už jde o nasazení na server, publikaci knihovny na npm nebo přiložení do jiného projektu. Kód v této složce bývá minifikovaný, tedy zbavený zbytečných mezer, komentářů a dlouhých názvů proměnných, což výrazně snižuje velikost výsledných souborů a zrychluje jejich načítání v prohlížeči. Obsah dist složky se generuje automaticky pomocí nástrojů jako Webpack, Rollup, Vite nebo esbuild a ve většině projektů se do repozitáře nepřidává, protože ho lze kdykoliv znovu vytvořit ze zdrojového kódu.

Složka build je svým způsobem podobná dist, ale používá se často v jiném kontextu. Zatímco dist bývá typická pro knihovny a balíčky určené k opětovnému použití jinými vývojáři, build se častěji objevuje u kompletních aplikací, například těch vytvořených pomocí Reactu přes Create React App nebo podobných nástrojů. Obsahuje zkompilovanou aplikaci připravenou k nasazení na produkční server, včetně HTML souborů, statických assetů, obrázků a optimalizovaných JavaScriptových balíčků. Rozdíl mezi dist a build je tedy často spíše konvenční než technický – oba adresáře slouží k uložení výsledného, produkčně připraveného kódu, ale jejich název odráží zvyk konkrétního nástroje nebo komunity, která daný projekt vyvíjí.

V praxi je důležité si uvědomit, že žádná z těchto složek by neměla být upravována ručně, protože při dalším spuštění build procesu by se veškeré manuální zásahy ztratily. Pokud vývojář potřebuje něco změnit, měl by úpravu provést vždy ve zdrojovém kódu ve složce src a následně spustit příslušný příkaz, který vygeneruje nový obsah do dist nebo build. Tento princip zajišťuje, že projekt zůstává konzistentní, přehledný a snadno udržitelný i při spolupráci více vývojářů najednou.

Role souborů package.json a node_modules

Když se člověk poprvé dostane k jakémukoliv reálnému JavaScript projektu, dřív nebo později narazí na dva prvky, které tvoří samotné jádro organizace kódu – soubor package.json a složku node_modules. Bez nich si moderní vývoj v JavaScriptu prakticky nelze představit, protože právě tyto dvě věci definují, jak se projekt chová, co potřebuje ke svému běhu a jak je strukturován v rámci celého adresáře zdrojového kódu.

Soubor package.json je v podstatě rodný list každého projektu. Jde o textový soubor ve formátu JSON, který obsahuje metadata o aplikaci nebo knihovně – název, verzi, popis, autora, licenci, ale především seznam závislostí, které projekt potřebuje k tomu, aby vůbec fungoval. Tyto závislosti se dělí na produkční (dependencies) a vývojové (devDependencies), přičemž první skupina obsahuje knihovny nutné pro běh aplikace samotné, zatímco druhá skupina zahrnuje nástroje potřebné jen během vývoje, jako jsou testovací frameworky, linterové nástroje nebo transpilery. Kromě toho package.json definuje i takzvané skripty – krátké příkazy, které lze spustit pomocí npm run nebo yarn run a které usnadňují opakující se úkony, jako je spuštění testů, sestavení produkční verze nebo start lokálního serveru.

Ve chvíli, kdy vývojář zadá příkaz pro instalaci závislostí, správce balíčků – dnes nejčastěji npm, yarn nebo pnpm – přečte obsah package.json a na jeho základě stáhne všechny potřebné knihovny do složky node_modules. Tato složka tak funguje jako lokální úložiště všech externích balíčků, které projekt využívá. Může obsahovat desítky, ale často i tisíce podadresářů, protože každá knihovna může mít své vlastní závislosti, které se instalují jako součást stromu závislostí. Právě proto bývá node_modules notoricky známá svou velikostí – u větších projektů může zabírat stovky megabajtů až několik gigabajtů diskového prostoru.

Důležité je zmínit, že node_modules se v praxi nikdy nepřidává do verzovacího systému jako je Git. Místo toho se do repozitáře ukládá pouze package.json a soubor package-lock.json (nebo yarn.lock), který přesně zaznamenává, jaké verze jednotlivých balíčků byly použity. Díky tomu může kdokoliv jiný, kdo projekt naklonuje, jednoduše spustit instalační příkaz a získat přesně stejné prostředí, aniž by musel řešit kompatibilitu verzí manuálně.

Struktura adresáře s JavaScriptovým kódem tak obvykle vypadá tak, že na nejvyšší úrovni najdeme právě package.json, lock soubor, složku node_modules a dále vlastní zdrojové soubory, často rozdělené do podadresářů podle funkce – například src pro zdrojový kód, test pro testy nebo dist pro výstupní sestavené soubory. Tato organizace umožňuje udržet přehled i v rozsáhlých projektech a zároveň zajišťuje, že závislosti třetích stran jsou oddělené od vlastního kódu aplikace, což zjednodušuje údržbu, aktualizace i případné odstraňování nepotřebných knihoven.

Moduly ES a organizace importů

Když se dnes podíváte na strukturu jakéhokoliv modernějšího JavaScriptového projektu, jen málokdy narazíte na jediný obrovský soubor obsahující veškerou logiku aplikace. Naopak, kód bývá rozdělen do desítek či stovek menších souborů, které jsou organizovány do adresářové struktury podle funkčních celků, vrstev aplikace nebo domén. Tato dekomposice je umožněna právě díky ES modulům (ECMAScript modules), které se staly standardní součástí jazyka a dnes tvoří páteř organizace kódu jak v Node.js, tak v prohlížeči.

Podstatou ES modulů je, že každý soubor s příponou .js, .mjs nebo v případě TypeScriptu .ts může exportovat část svého obsahu pomocí klíčového slova export a jiné soubory jej mohou pomocí import začlenit do svého vlastního kódu. Díky tomu vzniká přirozená hierarchie závislostí – jeden modul se odvolává na druhý, ten na třetí a tak dále, čímž se vytváří graf importů. Právě tento graf pak nástroje jako Webpack, Vite nebo Rollup analyzují při sestavování finálního balíčku a rozhodují, co se má a nemá zahrnout do výsledného kódu určeného pro produkci.

Organizace importů v rámci složky nebo adresáře souborů kódu má přímý dopad na udržitelnost projektu. Osvědčeným zvykem je udržovat konzistentní pořadí importů – nejprve externí knihovny, poté interní moduly z jiných částí projektu a nakonec relativní importy z aktuálního adresáře. Tento přístup usnadňuje orientaci v kódu novým členům týmu i samotnému autorovi, který se po měsících vrací k vlastnímu projektu. Mnoho týmů dnes tuto konvenci navíc automatizuje pomocí nástrojů jako ESLint s pluginem eslint-plugin-import nebo Prettier, které dokážou importy nejen kontrolovat, ale i automaticky přeuspořádat podle definovaných pravidel.

Dalším důležitým aspektem je rozlišování mezi named exports a default exports. Zatímco named export umožňuje z jednoho souboru exportovat více pojmenovaných hodnot, funkcí nebo tříd, default export slouží k označení jedné hlavní věci, kterou modul reprezentuje. V praxi se v roce 2026 stále více projektů přiklání k výhradnímu používání named exports, protože usnadňují refaktoring, poskytují lepší podporu pro automatické doplňování v editorech a snižují riziko nekonzistentního pojmenování při importu na různých místech kódu.

Zvláštní kapitolou je pak takzvaný barrel export, tedy soubor index.js umístěný v kořeni adresáře, který reexportuje obsah ostatních souborů ve složce. Tento přístup zjednodušuje importy z pohledu ostatních částí aplikace, avšak může způsobovat problémy s cyklickými závislostmi a zbytečně zvětšovat balíček, pokud bundler nedokáže efektivně provést tzv. tree-shaking. Proto zkušení vývojáři v roce 2026 tento vzor používají uvážlivě a spíše u menších, dobře ohraničených modulů, kde přínos v podobě čistších importů převažuje nad riziky spojenými s neefektivní eliminací nepoužívaného kódu.

Konvence pojmenování souborů a složek

Konvence pojmenování souborů a složek v JavaScriptových projektech se v průběhu let ustálily do podoby, kterou dnes respektuje naprostá většina vývojářů, ať už pracují na malém osobním projektu, nebo na rozsáhlé aplikaci pro firemního klienta. Základním pravidlem, které platí prakticky univerzálně, je používání kebab-case pro názvy souborů a složek – tedy zápis, kde jsou jednotlivá slova oddělena pomlčkou a psána malými písmeny, například user-profile.js nebo shopping-cart-utils.js. Tento přístup má praktický důvod: mnoho operačních systémů a souborových systémů rozlišuje velká a malá písmena nekonzistentně, takže pomlčky a malá písmena eliminují riziko, že se na jednom stroji soubor najde a na druhém ne kvůli rozdílné velikosti písmen v názvu.

U souborů obsahujících třídy nebo komponenty, zejména v ekosystému frameworků jako React či Vue, se ale často setkáváme i s PascalCase, kdy každé slovo v názvu začíná velkým písmenem, například UserProfileCard.jsx. Tento zápis přímo odráží název exportované komponenty nebo třídy, což usnadňuje orientaci – vývojář na první pohled pozná, že se jedná o komponentu, a ne o pomocnou funkci nebo konfigurační soubor. Naopak pro obyčejné utility, pomocné funkce, konstanty nebo konfigurace se drží spíše kebab-case nebo camelCase, kde první slovo začíná malým písmenem a další velkým, jako je tomu u formatDate.js.

Pokud jde o samotnou strukturu složek, projekty se obvykle organizují buď podle typu souboru, nebo podle funkčnosti. Při organizaci podle typu vznikají složky jako components, services, utils, hooks nebo styles, do kterých se ukládají soubory bez ohledu na to, ke které části aplikace logicky patří. Naproti tomu organizace podle funkčnosti, někdy nazývaná feature-based struktura, seskupuje veškerý kód týkající se jedné funkce aplikace do jedné složky – takže složka cart může obsahovat komponentu, styly, testy i pomocné funkce vztahující se výhradně k nákupnímu košíku. Tento přístup se v posledních letech těší velké oblibě, protože usnadňuje škálování projektu a snižuje riziko, že se při úpravě jedné funkce zapomene na související soubory roztroušené po celém projektu.

Důležitou zásadou zůstává také konzistence napříč celým projektem. Pokud se tým rozhodne pro určitou konvenci, měl by ji dodržovat důsledně ve všech souborech, protože smíšené styly pojmenování vedou ke zmatkům a ztěžují orientaci novým členům týmu. Mnoho firem proto konvence pojmenování explicitně zapisuje do interní dokumentace nebo je vynucuje pomocí nástrojů typu ESLint, které dokážou upozornit na nesprávný formát názvu souboru přímo během vývoje. Zvláštní pozornost si zaslouží i speciální soubory, jako jsou index.js, které slouží jako vstupní bod složky, nebo soubory s příponou .test.js či .spec.js, jejichž pojmenování jasně signalizuje, že obsahují testy, nikoli produkční kód.

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

Když otevřete jakoukoliv složku obsahující soubory napsané v JavaScriptu, dříve nebo později narazíte na potřebu spravovat závislosti, tedy externí knihovny a balíčky, které váš kód využívá. Právě k tomu slouží nástroje jako npm a pnpm, které se v roce 2026 staly naprostým standardem téměř každého projektu, ať už jde o malý osobní skript, nebo rozsáhlou aplikaci vyvíjenou týmem desítek programátorů.

npm (Node Package Manager) je nejstarší a nejrozšířenější správce balíčků pro JavaScript. Instaluje se automaticky společně s Node.js a v adresáři projektu vytváří soubor package.json, ve kterém jsou zaznamenány veškeré závislosti, jejich verze i skripty potřebné pro spuštění, build nebo testování aplikace. Když v terminálu zadáte příkaz pro instalaci, npm stáhne požadované balíčky do složky node_modules, která se v praxi bohužel proslavila svou velikostí – u větších projektů dokáže zabrat stovky megabajtů až jednotky gigabajtů místa na disku. Právě tato neefektivita byla jedním z hlavních důvodů, proč vznikly alternativní nástroje.

pnpm řeší problém s duplicitními soubory zcela odlišným přístupem. Místo toho, aby pro každý projekt kopíroval stejné balíčky znovu a znovu, ukládá je do centrálního úložiště na disku a do jednotlivých projektů vytváří pouze symbolické odkazy. Výsledkem je výrazná úspora místa a také podstatně rychlejší instalace, což ocení zejména vývojáři pracující na více projektech současně nebo v prostředí s omezenou kapacitou disku, jako jsou třeba CI/CD servery. V roce 2026 patří pnpm mezi velmi oblíbené volby u nových projektů právě díky této efektivitě a také díky přísnější kontrole závislostí, která zabraňuje takzvanému „phantom dependencies problému, kdy kód nečekaně funguje díky balíčku, který ve skutečnosti není deklarován jako přímá závislost.

Oba nástroje pracují se stejnou strukturou souborů a adresářů typickou pro JavaScriptové projekty. Ve složce s kódem tak běžně najdete zmíněný package.json, dále lock soubor (package-lock.json u npm nebo pnpm-lock.yaml u pnpm), který zajišťuje, že všichni členové týmu i produkční prostředí používají naprosto identické verze balíčků, a samozřejmě samotné zdrojové soubory s příponou .js nebo v případě TypeScriptu .ts. Správná organizace této struktury je klíčová pro udržitelnost projektu, protože i nepatrná nesrovnalost ve verzích balíčků dokáže způsobit těžko odhalitelné chyby.

Výběr mezi npm a pnpm dnes často závisí na konkrétních potřebách projektu, velikosti týmu a preferencích vývojářů. Zatímco npm zůstává díky své univerzálnosti a integraci s Node.js výchozí volbou pro začátečníky i menší projekty, pnpm si získává čím dál větší oblibu u komplexnějších monorepo architektur, kde jeho efektivní správa závislostí a rychlost přinášejí citelné zlepšení produktivity celého vývojářského týmu.

Bundlery Vite a jejich výstupní adresáře

Vite se v posledních letech stal prakticky standardem pro rychlý vývoj JavaScriptových aplikací a v roce 2026 jeho popularita nadále roste, ať už se jedná o samostatné projekty nebo o kombinaci s frameworky jako React, Vue nebo Svelte. Zásadní roli v tom hraje způsob, jakým Vite pracuje se zdrojovým kódem a jak jej následně transformuje do podoby vhodné pro nasazení na produkční servery. Pochopení výstupních adresářů je proto klíčové pro každého, kdo chce se svým projektem pracovat efektivně a předejít zbytečným komplikacím při nasazování.

Ve výchozím nastavení Vite generuje výstupní soubory do složky nazvané dist. Tento adresář vzniká automaticky při spuštění příkazu pro produkční sestavení a obsahuje veškeré zoptimalizované soubory, které jsou připravené k nasazení – tedy zminifikovaný JavaScript, CSS, obrázky a další statické soubory, které aplikace potřebuje k běhu. Na rozdíl od zdrojového adresáře, kde se nachází nezpracovaný kód napsaný vývojáři, adresář dist obsahuje výsledek celého sestavovacího procesu, tedy kód, který prošel bundlerem, byl transformován, sloučen do menšího počtu souborů a zbaven zbytečných částí, jako jsou komentáře nebo nepotřebné importy.

Je důležité si uvědomit, že tento výstupní adresář nemá smysl verzovat v Gitu, protože se jedná o generovaný obsah, který se vytváří znovu při každém sestavení. Proto se ve výchozím nastavení .gitignore souboru téměř vždy objevuje řádek, který tuto složku z verzování vylučuje. Vývojáři by měli tento zvyk respektovat i ve vlastních projektech, protože zbytečné verzování vygenerovaných souborů zpomaluje práci s repozitářem a může vést k matoucím konfliktům při slučování změn.

Vite nicméně umožňuje tuto výchozí konfiguraci snadno upravit. V konfiguračním souboru vite.config.js nebo vite.config.ts lze pomocí vlastnosti build.outDir určit jiný název nebo umístění výstupní složky. To se hodí zejména ve chvíli, kdy je potřeba přizpůsobit strukturu projektu specifickým požadavkům hostingové platformy nebo CI/CD procesu, kde se očekává jiný název adresáře, například build nebo public_html. Tato flexibilita je jedním z důvodů, proč se Vite tak dobře integruje do různých typů infrastruktury, ať jde o statické hostingy, cloudové platformy nebo tradiční servery.

Kromě samotného adresáře pro výstup je vhodné zmínit i to, jak Vite pracuje se statickými soubory během vývoje. Složka public slouží jako místo pro soubory, které se během sestavení kopírují do výstupního adresáře beze změny, tedy bez zpracování bundlerem. To je typické například pro favicon, manifesty nebo jiné soubory, které musí zůstat na stejné cestě bez ohledu na to, jak Vite optimalizuje ostatní části aplikace.

Pro vývojáře, kteří pracují s většími projekty rozdělenými do více modulů nebo mikroaplikací, může být užitečné také sledovat, jak Vite generuje podadresáře pro jednotlivé části kódu, včetně assetů, JavaScriptových chunků a CSS souborů. Tyto podadresáře se obvykle vytvářejí automaticky uvnitř hlavního výstupního adresáře a jejich struktura odráží způsob, jakým Vite rozděluje kód pro lepší výkon při načítání stránky, což je zásadní pro moderní webové aplikace optimalizované na rychlost.

Struktura projektů React a Node.js

Když se ponoříte do jakéhokoli moderního projektu psaného v JavaScriptu, ať už jde o frontendovou aplikaci v Reactu nebo backendový server v Node.js, narazíte na poměrně ustálený způsob organizace složek a souborů. Tato struktura se v průběhu let vykrystalizovala z praxe tisíců vývojářů a dnes ji najdete v drtivé většině repozitářů, které si stáhnete z GitHubu nebo vygenerujete pomocí nástrojů jako Create React App, Vite nebo Next.js.

Základem každého projektu je kořenový adresář, ve kterém leží soubor package.json. Ten obsahuje metadata o projektu, seznam závislostí a skripty pro spouštění, build nebo testování. Vedle něj se často vyskytuje soubor package-lock.json nebo yarn.lock, který zajišťuje konzistentní verze knihoven mezi jednotlivými instalacemi. Samotný kód JavaScriptu se pak typicky nachází ve složce nazvané src, což je zkratka pro „source“. Tato složka je srdcem celého projektu a její vnitřní členění se liší podle toho, zda se jedná o React aplikaci, nebo o Node.js server.

U React projektů se ve složce src obvykle setkáte s podadresářem components, kde jsou uloženy jednotlivé znovupoužitelné komponenty uživatelského rozhraní. Každá komponenta má často svůj vlastní soubor s přípdou .jsx nebo .tsx, pokud se používá TypeScript. Dále se běžně objevuje složka pages nebo views, která obsahuje komponenty reprezentující jednotlivé stránky nebo obrazovky aplikace. Nechybí ani adresář hooks pro vlastní React hooky, context pro správu globálního stavu pomocí Context API a assets nebo styles pro obrázky, fonty a kaskádové styly. V posledních letech se prosazuje i takzvaná feature-based struktura, kde se soubory neorganizují podle typu, ale podle funkčních modulů aplikace – tedy vše, co souvisí s přihlašováním, je v jedné složce, vše, co se týká objednávek, v jiné.

Na straně Node.js bývá struktura poněkud odlišná, protože jde o serverovou logiku bez uživatelského rozhraní. Typicky se setkáte se složkou routes, kde jsou definovány jednotlivé API endpointy, dále controllers, které obsahují logiku obsluhující požadavky, a models, kde se definují datové struktury a schémata pro databázi, ať jde o MongoDB s knihovnou Mongoose nebo relační databázi s ORM nástrojem jako Prisma či Sequelize. Často se objevuje i složka middlewares pro funkce zpracovávající požadavky před jejich doručením do controlleru, a config, kde se ukládají konfigurační soubory pro připojení k databázi, proměnné prostředí nebo nastavení autentizace.

Společným rysem obou typů projektů je snaha o oddělení odpovědností a co nejvyšší míru modularity. Díky tomu se v roce 2026 i velké týmy dokážou v rozsáhlých kódových základnách orientovat rychle a efektivně, protože každá logická část aplikace má své přesně vymezené místo.

Bezpečnostní rizika sdílených JavaScript složek

Sdílené složky s JavaScript soubory představují v roce 2026 jedno z nejpodceňovanějších bezpečnostních rizik ve vývoji webových aplikací. Když více vývojářů nebo dokonce celých týmů přistupuje ke stejnému adresáři kódu, ať už přes síťové úložiště, cloudové synchronizační nástroje nebo sdílené repozitáře bez důsledné kontroly přístupu, otevírá se prostor pro celou řadu problémů, které mohou zůstat neodhaleny až do okamžiku, kdy už napáchají skutečnou škodu. Největším rizikem je neoprávněná modifikace kódu, kdy se do sdílené složky dostane osoba bez patřičných oprávnění a vloží do některého ze souborů škodlivý skript, který se následně spustí u všech uživatelů dané aplikace.

Typickým scénářem je situace, kdy se v rámci jedné složky nachází knihovny třetích stran spolu s vlastním kódem projektu. Pokud se do takového adresáře dostane útočník, může snadno upravit existující funkci tak, aby kromě své původní činnosti navíc odesílala citlivá data, jako jsou přihlašovací údaje nebo platební informace, na externí server. Vzhledem k tomu, že JavaScript se v prohlížeči spouští přímo na straně klienta, je odhalení takového škodlivého kódu často velmi obtížné, protože se snadno schová mezi stovky řádků legitimního kódu, minifikovaných souborů nebo generovaných buildů.

Dalším závažným problémem je nedostatečná verzovací kontrola u sdílených složek, které nejsou napojené na systém jako Git. V praxi se stále setkáváme s případy, kdy týmy pracují se sdíleným diskem přes protokoly typu SMB nebo přes cloudové úložiště, aniž by měly přehled o tom, kdo a kdy jaký soubor upravil. Tato absence auditní stopy znamená, že v případě bezpečnostního incidentu je prakticky nemožné zpětně zjistit, kdo je za problém zodpovědný a jak dlouho už je škodlivý kód v produkci aktivní.

Velké riziko představují také závislosti a balíčky stažené z veřejných repozitářů, které se následně ukládají do sdílené složky node_modules nebo obdobných adresářů. Pokud tato složka není pravidelně kontrolována a aktualizována, mohou v ní zůstat zastaralé knihovny se známými zranitelnostmi, které útočníci aktivně vyhledávají a zneužívají. V roce 2026 je navíc čím dál běžnější takzvaný supply chain útok, kdy je škodlivý kód vložen přímo do legitimně vypadajícího balíčku, který se pak automaticky stáhne do sdílené složky všech členů týmu.

Neméně důležitým aspektem je i otázka práv k zápisu do sdílených složek. Pokud mají všichni členové týmu, včetně externích spolupracovníků nebo stážistů, plná oprávnění k úpravě jakéhokoliv souboru, výrazně se tím zvyšuje pravděpodobnost nechtěné chyby i úmyslného zneužití. Doporučuje se proto důsledné oddělení produkčního a vývojového prostředí, pravidelné bezpečnostní audity kódu, používání nástrojů pro statickou analýzu a striktní řízení přístupových práv na základě principu minimálních oprávnění, což výrazně snižuje riziko kompromitace celého projektu.

Nejlepší praktiky organizace velkých projektů

Organizace velkého JavaScript projektu se nikdy neobejde bez pečlivě promyšlené struktury složek a souborů. Jakmile se aplikace rozroste z několika stovek řádků na desítky tisíc, chaotické uspořádání se stává noční můrou pro každého vývojáře, který se k projektu připojí později nebo se do kódu musí vrátit po delší době. Základním pravidlem je oddělení odpovědností podle funkčnosti, nikoliv podle typu souboru. Namísto toho, aby všechny komponenty ležely v jedné složce, všechny služby v jiné a všechny testy ve třetí, je mnohem efektivnější vytvořit strukturu podle modulů nebo funkčních oblastí, kde každá složka obsahuje vše, co k dané funkcionalitě patří – komponenty, logiku, styly i testy.

Velmi důležitým prvkem je také konzistentní pojmenování souborů a složek. Pokud tým používá camelCase pro proměnné, ale kebab-case pro názvy souborů, může to na první pohled působit jako drobnost, avšak při práci s desítkami vývojářů a tisíci soubory se takové nesrovnalosti stávají zdrojem zbytečných chyb a zmatků. Doporučuje se stanovit jasnou konvenci hned na začátku projektu a tu důsledně dodržovat, ideálně s pomocí automatizovaných nástrojů jako ESLint nebo Prettier, které dokážou odchylky odhalit už při psaní kódu.

Neméně klíčovým aspektem je oddělení konfigurace od byznysové logiky. Velké projekty by měly mít samostatnou složku pro konfigurační soubory, proměnné prostředí a nastavení buildu, aby nedocházelo k promíchávání technických detailů s vlastní logikou aplikace. Podobně je vhodné vytvořit samostatnou vrstvu pro komunikaci s externími API nebo databázemi, díky čemuž lze snadněji testovat a v případě potřeby nahradit konkrétní implementaci bez zásahu do zbytku kódu.

V roce 2026 se stále více projektů přiklání k monorepo přístupu, zejména díky nástrojům jako Turborepo nebo Nx, které umožňují správu více balíčků a aplikací v rámci jednoho úložiště. Tento přístup usnadňuje sdílení kódu mezi frontendem a backendem, avšak vyžaduje ještě přísnější disciplínu při organizaci složek, protože jedna nekonzistence se může promítnout do více částí systému najednou.

Dokumentace uvnitř samotné struktury projektu, ať už formou README souborů v jednotlivých složkách nebo komentářů popisujících účel konkrétního modulu, je často podceňovaným, ale nesmírně užitečným zvykem. Nový člen týmu se tak rychleji zorientuje a nemusí ztrácet čas zkoumáním, k čemu daná část kódu vlastně slouží.

Rovněž je vhodné pravidelně revidovat strukturu projektu a nebát se refaktoringu, pokud se ukáže, že původní organizace již neodpovídá aktuálním potřebám. Statická struktura, která se nikdy nemění, může časem bránit růstu projektu stejně jako naprostý chaos. Zdravá rovnováha mezi pevnými pravidly a flexibilitou k jejich úpravě je tím, co odlišuje udržitelné velké JavaScript projekty od těch, které se postupem času stávají neudržitelnými.

Budoucí trendy ve struktuře JavaScript kódu

V roce 2026 se organizace JavaScript kódu do složek a adresářů posouvá směrem k větší modularitě a autonomii jednotlivých částí aplikace. Namísto klasického dělení podle typu souboru, kde se historicky oddělovaly složky pro komponenty, styly a logiku, se prosazuje přístup, kdy se struktura odvíjí od funkčních domén a byznysové logiky. To znamená, že vývojáři vytvářejí adresáře pojmenované podle konkrétních funkcí aplikace, například správa uživatelů, platební brána nebo systém notifikací, a uvnitř každé takové složky se soustředí veškerý související kód, ať se jedná o soubory s logikou, testy nebo pomocné utility. Tento přístup, často označovaný jako feature-based nebo domain-driven struktura, výrazně zjednodušuje orientaci ve velkých projektech a usnadňuje týmovou spolupráci, protože jednotliví vývojáři mohou pracovat na oddělených částech kódu bez zbytečných konfliktů.

Dalším trendem, který se v posledních letech prosazuje, je rostoucí důraz na takzvané monorepo architektury, kde jedna složka obsahuje více na sobě závislých, ale samostatně publikovatelných balíčků. Nástroje jako Turborepo nebo Nx se staly standardem pro správu takto rozsáhlých kódových základen a umožňují efektivní sdílení kódu mezi frontendovými a backendovými částmi aplikace psanými v JavaScriptu nebo TypeScriptu. Tento způsob organizace přináší výhody v podobě jednotné verzování a snadnější údržby sdílených knihoven, což je zásadní zejména pro větší firmy, které provozují desítky souvisejících projektů současně.

Významným posunem je také automatizace generování struktury souborů pomocí konfigurovatelných šablon a generátorů kódu. Vývojáři už nemusí manuálně vytvářet stejné adresářové vzory pro každou novou komponentu nebo modul, ale spoléhají na nástroje integrované přímo do vývojového prostředí, které dodržují stanovené konvence týmu. Tím se snižuje riziko nekonzistence a chyb způsobených lidským faktorem. Souběžně s tím roste popularita takzvaných plochých struktur souborů, kde se hluboké zanořování adresářů nahrazuje jasně pojmenovanými soubory na jedné úrovni, což usnadňuje vyhledávání pomocí moderních editorů kódu s pokročilým fulltextovým vyhledáváním.

Nelze opomenout ani vliv nástrojů pro statickou analýzu a takzvané architektonické linters, které kontrolují, zda struktura kódu odpovídá definovaným pravidlům projektu, tedy zda se moduly nenačítají mimo povolené hranice a zda nedochází k nežádoucím cyklickým závislostem. Tato pravidla se stávají nedílnou součástí CI/CD procesů, což pomáhá udržet čistotu a udržitelnost i velmi rozsáhlých aplikací v čase.

V souvislosti s rozšířením serverových komponent a frameworků jako Next.js nebo Remix se také mění chápání toho, co je vlastně jeden logický celek kódu, protože hranice mezi frontendem a backendem se stále více rozpouštějí. Adresáře tak často obsahují kombinaci klientského a serverového kódu, který spolu logicky souvisí, i když běží v odlišných prostředích. Tento trend ukazuje, že budoucnost organizace JavaScript projektů směřuje k větší flexibilitě, srozumitelnosti pro nové členy týmu a k minimalizaci technického dluhu, který v minulosti vznikal právě z nekonzistentní a chaotické adresářové struktury.