Vite+ mi změnil způsob, jakým stavím aplikace s AI

V jednom projektu jsem měl 47 vývojových závislostí, sedm konfiguračních souborů a ještě jeden Markdown, který agentovi vysvětloval, jak to celé spustit. Ve dvě ráno jsem pak řešil rozdíl mezi lokální kontrolou a CI. Samotný kód byl hotový; já ladil nástroje okolo něj. Po třech týdnech s Vite+ na čtyřech různých projektech mám pro nové aplikace na Vite jednoduché pravidlo: chci ho už v prvním zadání pro AI.

Ve zkratce

• Pro novou aplikaci na Vite nechávám agenta založit projekt přes vp create a kontrolu dokončené práce přes vp check, vp test a vp build.
• Zrychlení je příjemné, ale větší přínos vidím v jednom srozumitelném postupu pro mě, agenta i CI.
• U existujícího projektu beru vp migrate jako začátek migrace. Diff, testy a chování buildu pořád kontroluju.

Problém nebyl pomalý linter

Měl jsem příkazy rozložené mezi ESLint, Prettier, TypeScript, test runner a skripty v package.json. Když jsem do projektu pustil agenta, nejdřív musel zjistit, který z nich je ten správný. Napsal jsem mu kvůli tomu instrukce. Tím jsem vyrobil další soubor, který bylo potřeba udržovat. Výborná úspora práce, že ano.

Nešlo jen o počet souborů. Lokální prostředí a CI mi jednou kontrolovaly vygenerovaný soubor rozdílně. Agent viděl jeden výsledek, pipeline jiný. Takovou chybu nevyřeší rychlejší generování komponent.

Vite+ sjednocuje běžnou práci pod vp: Vite pro vývoj a build, Vitest pro testy, Oxlint a Oxfmt pro kontroly, tsdown pro knihovny a Vite Task pro úlohy. Nastavení těchto nástrojů můžeš držet ve vite.config.ts. Pořád ale máš package.json, tsconfig a podle projektu i konfiguraci frameworku. Tvrzení „jeden soubor na úplně všechno“ by bylo hezké na banneru a špatné v reálném repu.

V React aplikaci mi po vytvoření projektu stačí znát tuto sadu:

Příkazy výše počítají s globálně dostupným vp. Globální instalace je volitelná; Vite+ jde spustit i jako lokální závislost přes správce balíčků. vp install sám používá správce balíčků zvolený v projektu, takže Vite+ nenahrazuje npm nebo pnpm.

Agentovi nenechávám hádat, co znamená hotovo

V dokumentaci Vite+ je připravený prompt pro AI asistenta. Je užitečný jako start, ale vlastní zadání si upravuju podle projektu. Můj cíl je konkrétní: agent má použít Vite+ při založení a po první vygenerované stránce ho potichu neopustit.

Nevynucuju globální instalaci přes curl v každém projektu. Pro jednorázový start stačí třeba npx --package=vite-plus@1.3.0 vp create; v hotovém projektu může agent spouštět lokální CLI přes zvolený package manager. A nezakazuju create-vite jako takové: vp create vite tuhle šablonu používá. Důležité je, aby agent vytvořil projekt zamýšleným postupem a zachoval jeden konzistentní toolchain.

Když jsem agentovi nechal volnou ruku, skončil jsem s kombinací Prettieru a Oxfmtu, třemi lockfily a nespolehlivou CI. Zákaz druhého formatteru a požadavek na jeden lockfile nejsou stylistické preference. Jsou to dvě konkrétní chyby, které už nechci znovu řešit.

Jeden příkaz mi vrátí rychlý feedback

Po změně kódu spouštím vp check. Zkontroluje formátování a lint; TypeScript kontroluje tehdy, když jsou v konfiguraci zapnuté typeAware i typeCheck. Nový projekt založený přes vp create je zapíná ve výchozím nastavení. U převzatého projektu si to ověřím místo předpokladu, že zelený výstup znamená i správné typy.

Tohle je rozdíl proti mému starému postupu:

vp check může některé nálezy automaticky opravit přes vp check --fix. Po takové opravě čtu diff a kontrolu spouštím znovu. Zelený lint taky neříká, že aplikace dělá správnou věc. Na chování potřebuji testy přes vp test, na sestavení aplikace vp build.

Tohle pravidlo ukládám i do souboru s instrukcemi pro agenta v repu. Když se vrátím k projektu za týden, nový agent nezná včerejší chat. Repo zná svoje příkazy pořád.

Lokální instrukce a Git hooky jsou užitečné, ale dají se obejít nebo vypnout. Proto stejné kontroly patří i do CI. U experimentu, kde jsem nechal agenta pracovat bez dozoru, byl lidský review před mergem pořád moje odpovědnost.

Kde jsem naměřil rozdíl

V monorepu se mi po změně workflow zkrátil běh CI ze 4 minut na 50 sekund. Pre-commit kontrola se z 11 sekund dostala pod 2 sekundy. Jsou to výsledky z mých projektů, ne benchmark Vite+ proti jiné sadě nástrojů za stejných podmínek. Část zisku jde za tím, co se spouští a na jakých souborech; bez stejné konfigurace je nepřeneseš do vlastního CI.

Pro rychlé kontroly změněných souborů používám vp staged a Git hooky spravované přes vp hooks. Když mám problém s odlišným chováním mezi projekty, vp toolchain mi ukáže jejich aktivní verze. vp toolchain --global ukáže globální instalaci. To je při ladění užitečnější než moje stará metoda „vždyť jsem to přece aktualizoval“.

U úloh v monorepu je potřeba rozlišit dvě věci. vp run spustí skript z package.json nebo úlohu definovanou ve vite.config.ts; umí řadit práci podle závislostí mezi workspaces. Skripty v package.json ale nemají cache zapnutou automaticky. Pro ně ji zapínáš například přes vp run --cache build. Úlohy definované v vite.config.ts se naopak cachují ve výchozím stavu. Z mého času CI proto nedělám slib, že samotné vp run zrychlí každý build.

Kde to drhlo

Migraci staršího monorepa spustil vp migrate zhruba za 4 minuty. Převedl mi nastavení okolo ESLintu, Prettieru a původního tsup buildu a v mém případě se nic nerozbilo. To neznamená, že je migrace na čtyři minuty hotová v každém repu. Výsledek musíš porovnat s původním lintem, testy, hooky a výstupem buildu. U pluginů a vlastních pravidel může zůstat ruční práce.

Druhá past je rozdíl mezi vestavěným příkazem a skriptem projektu. vp build spouští build aplikace přes Vite. vp run build spouští build z package.json nebo stejnojmennou úlohu. V Next.js projektu si proto agent nesmí domyslet, že vp build nahradí next build. Totéž platí pro vp dev a vp run dev. Vite+ umí pracovat i s dalšími šablonami, ale význam příkazů se tím nemění.

Třetí věc je správa verzí. Globální vp env umí spravovat Node.js a package managery. Mám tři projekty na třech verzích Node a v tomhle mi zjednodušil přepínání; kdo to nechce, může správu prostředí vypnout přes vp env off. Příkaz vp upgrade aktualizuje globální CLI, nikoli automaticky lokální balíček vite-plus v každém projektu. To jsem si do instrukcí pro agenta napsal výslovně, protože název příkazu svádí k opačnému očekávání.

Komu bych Vite+ dal do prvního promptu

Každému, kdo začíná novou aplikaci na Vite a nechává ji zakládat AI. Tady je cena za sjednocení malá: zvolíš jeden toolchain, zapíšeš kontrolní příkazy do repa a CI a agent má jasnou cestu od změny k ověření. Za tři týdny na čtyřech projektech mi to pomohlo hlavně tím, že jsem přestal znovu vysvětlovat základní příkazy.

Netlačil bych migraci naslepo do velké existující aplikace s funkčním buildem a testy. U frameworku s vlastním buildem bych nejdřív rozhodl, které části Vite+ skutečně použiju. A kdybych měl už dobře popsaný, rychlý a stabilní stack, samotný slib „jednoho příkazu“ by mi na výměnu nestačil.

Při příštím zakládání Vite projektu dej agentovi vp create a do definice hotové práce přidej výstupy vp check, testů a buildu. Screenshot hotové aplikace je příjemný. Zelené kontroly ti řeknou víc.