Ptají se mě na to často. „Jakou frontendovou technologii bys dnes zvolil na nový projekt?" Moje odpověď je už nějakou dobu stejná: TanStack Start, a k němu zbytek TanStacku. Je to první věc, po které sáhnu, když zakládám nový projekt. A momentálně nemám jediný důvod to měnit.

V tomhle článku shrnu, co verze 1.0 znamená, co k tomu píše sám Tanner, a hlavně ukážu, jak Start používáme v produkci na dvou projektech, na tomhle webu bhpslabs.com a na aplikaci udalist.app. Bez teorie, na skutečném kódu.

Co znamená „1.0"#

Start běží v produkci u spousty firem už dlouho. Od malých projektů po enterprise týmy, a jak Tanner sám přiznává, řada z nich ho nasadila ještě v betě, i když jim to tým rozmlouval. My jsme na tom byli stejně.

Verze 1.0 proto není o tom, že by Start najednou začal fungovat. Je to formální závazek k API. Můžete si Start vybrat, naučit se ho, postavit na něm produkt a nemusíte se bát, že vám za půl roku překope celý způsob, jakým aplikace funguje. Pro firmu, která na technologii sází peníze a lidi, je tohle ta nejdůležitější vlastnost ze všech.

Tanner taky otevřeně píše, že cesta od release candidate k 1.0 trvala déle, než čekal. Mezitím do frameworku přibyla práce na kompilátoru, streamingu, hydrataci a hranicích mezi serverem a klientem. Manuel Schiller a Florian Pellet se zaměřili na výkon SSR a v jejich benchmarku dostali zhruba 5,5× vyšší propustnost. Christopher Horobin stojí za tím, že extrémně silné typy routeru nezaseknou editor. To jsou věci, které v changelogu nevypadají dramaticky, ale v produkci je poznáte.

Co Tanner v článku říká (a proč s ním souhlasím)#

Celý článek doporučuju přečíst v originále. Pro ty, kdo nemají čas, tady jsou body, které mi mluví z duše.

Všechno začalo routerem#

Start nevznikl jako framework. Vznikl jako router, u kterého Tanner chtěl, aby věděl všechno: jaké cesty existují, jaké parametry potřebují, jaké query parametry jsou platné, co vrací loader a jaký kontext je kde dostupný. A aby vám editor při každé změně řekl, co dalšího se musí upravit.

Před pár lety tomu spousta lidí nevěřila. Dnes je to podle mě největší důvod, proč TanStack Router a Start používat.

Jiná cesta než „všechno na serveru"#

Tanner popisuje, že React ekosystém se v posledních letech hodně zúžil na jednu představu o tom, jak má aplikace vypadat. Next.js vsadil na React Server Components jako základ frameworku i jako ideologii. Start jde jinudy: aplikace zůstane aplikací, se stavem, klientskou navigací a cachováním dat. Server rendering, streaming a server funkce přidáte tam, kde dávají smysl, ale nemusíte kvůli nim přepisovat celé uvažování o aplikaci.

Každá route si může vybrat, jestli se vykreslí na serveru, jestli na serveru jen načte data, nebo jestli poběží čistě na klientu. Server funkce jsou typované a volají se z loaderu i z event handleru. Middleware umí běžet na klientu i na serveru a typy kontextu jdou skrz.

RSC jako volba, ne povinnost#

Zajímavá pasáž je o React Server Components. Tým na nich strávil hodně času a Start je podporuje, ale tak, aby nepřevzaly kontrolu nad celou aplikací. A pointa: na tanstack.com je nakonec vypnuli, protože bylo čím dál těžší uvažovat o tom, co se kam posílá, a to platilo pro lidi i pro AI modely. Vypnutí přitom neznamenalo přepisovat aplikaci. To je přesně ten druh svobody, který od frameworku chci.

Hosting kdekoli#

Start stojí na Vite a Nitru (a nově umí i Rsbuild), takže nasazení není svázané s jedním poskytovatelem. Netlify, Vercel, Cloudflare, Railway, Render, nebo vlastní Docker kontejner s Node serverem, jak to děláme my.

Typy pomáhají i AI agentům#

Tohle považuju za nejvíc podceňovaný argument. Striktní typy a explicitní API vznikly pro lidi, ale AI agentům pomáhají úplně stejně. Když agent změní parametr route nebo vstup server funkce, TypeScript mu hned ukáže všechna místa, která s tou změnou nesouhlasí. TanStack navíc začal přidávat do npm balíčků takzvané skills (přes TanStack Intent), takže agent nemusí spoléhat na zastaralá trénovací data, ale čte aktuální doporučené postupy přímo z balíčku.

Proč jsem opustil Next.js#

Next.js jsem používal dlouho a nechci ho shazovat. Umí skvěle vysvětlit a prodat svou myšlenku a spoustu lidí to naučil. Jenže čím dál víc jsem měl pocit, že bojuju s frameworkem místo toho, abych stavěl produkt.

• "use client" a "use server" direktivy rozhodují o tom, kde kód běží, a hranice nejsou vždycky vidět.
• Cachování se v několika verzích za sebou změnilo od základu a bylo těžké odhadnout, co je cachované, kde a jak dlouho.
• Mentální model App Routeru je pro juniora (a upřímně i pro seniora) těžký: serverové komponenty, klientské komponenty, co smí importovat co.
• Typová bezpečnost routování je spíš doplněk než základ. Query parametry jsou v podstatě string | string[] | undefined.

U Startu je to opačně. Komponenty jsou komponenty, routy jsou routy, a když potřebuju server, napíšu to explicitně. Nemusím mít v hlavě druhý model aplikace, abych prošel běžným dnem.

S Tannerem jsem se potkal i osobně v Amsterdamu a ten rozhovor mi potvrdil, co jsem z kódu cítil dávno: za TanStackem je člověk, kterému jde o to, aby se nástroje dobře používaly, ne o to, aby se dobře prodávaly.

Developer experience a učící křivka#

DX je u Startu podle mě o třídu dál a nejlépe to ukáže pár konkrétních věcí.

Typované routy bez generování v hlavě. Router si sám generuje strom rout (routeTree.gen.ts). Odkaz na neexistující stránku nebo chybějící parametr je chyba při kompilaci, ne 404 v produkci. Na udalist.app máme přes 80 <Link> komponent a každá z nich je typově zkontrolovaná.

Query parametry jako typovaný stav. validateSearch (na Udalistu ho používá sedm rout) udělá z query parametrů validovaný a typovaný objekt. Filtry, stránkování nebo stav formuláře v URL přestanou být zdrojem chyb.

Explicitní server. Server funkce je obyčejná funkce, kterou zavoláte. Vidíte, co jde dovnitř, co jde ven a že běží na serveru. Žádná magie.

Učící křivka. Kdo zná React a umí trochu TypeScript, je ve Startu produktivní za pár dní. Nemusí se učit nový paradigma, jen router. A kdo zná TanStack Query, je doma ještě rychleji. U Next.js App Routeru jsem viděl zkušené vývojáře tápat týdny.

SEO a GEO: tady Start opravdu vyniká#

O SEO a GEO (Generative Engine Optimization, tedy optimalizaci pro AI asistenty typu ChatGPT, Claude nebo Perplexity) jsme na tomhle webu strávili hodně času. A Start nám v tom nestál v cestě ani jednou. Naopak.

Metadata u každé route#

Každá route má funkci head(), která vrací titulek, popis, canonical, hreflang, Open Graph i JSON-LD. Je typovaná, zná parametry route a běží při SSR, takže crawler dostane hotové HTML. Takhle zjednodušeně vypadá route tohoto článku:

export const Route = createFileRoute('/$locale/blog/$slug')({
    beforeLoad: ({ params }) => {
        if (!findPost(posts, params.locale, params.slug)) throw notFound();
    },
    head: ({ params }) => {
        const post = findPost(posts, params.locale, params.slug);
        return pageHead({
            title: post.title,
            description: post.description,
            ogType: 'article',
            alternates, // hreflang na překlad článku
            nodes: [blogPostingNode({ headline: post.title /* … */ })], // JSON-LD
        });
    },
    component: ArticlePage,
});

Všimněte si i beforeLoad. Starý tvar adresy přesměruje trvalým 301 a neexistující článek vrátí skutečnou 404, ne prázdnou stránku se stavovým kódem 200. Na tom SEO hodně záleží.

Prerender a sitemap přímo v konfiguraci#

Statické stránky necháváme předgenerovat při buildu a sitemap vzniká automaticky. Na obou projektech je to pár řádků ve vite.config.ts:

tanstackStart({
    pages: getTanstackStartPages(),
    prerender: { enabled: true, crawlLinks: false, autoStaticPathsDiscovery: false },
    sitemap: { enabled: true, host: 'https://bhpslabs.com/' },
}),

Na Udalistu má prerender navíc filtr, který vynechá přihlášenou část aplikace (dashboard, autentizaci). Marketingové stránky jsou tak statické a bleskové, aplikace za přihlášením běží jako klasická SPA.

Web, kterému rozumí i AI#

Tady se ukazuje síla toho, že Start nic neschovává. Vlastní serverový vstup (src/server.ts) je obyčejný fetch handler, do kterého si můžete přidat cokoli. Na bhpslabs.com díky tomu:

• vracíme stejnou stránku jako Markdown, když si o to AI agent řekne hlavičkou Accept: text/markdown. Agent nemusí parsovat HTML a dostane čistý text,
• skládáme Content-Security-Policy pro každou odpověď zvlášť z otisků inline skriptů, bez unsafe-inline,
• servírujeme soubory pod /.well-known/ pro objevování agenty (katalog, agent skills),
• k tomu robots.txt s pravidly pro AI crawlery a llms.txt, který modelům říká, co děláme a kdy nás doporučit.

export default {
    async fetch(request: Request) {
        const wellKnown = await wellKnownResponse(request);
        if (wellKnown) return wellKnown;

        const markdown = wantsMarkdown(request.headers.get('accept'));
        const response = await paraglideMiddleware(request, () => handler.fetch(request));

        if (markdown) return toMarkdownResponse(response);
        // … CSP z otisků inline skriptů, Vary, gzip
        return response;
    },
};

Udalist má velmi podobný vstup: Paraglide middleware, bezpečnostní hlavičky, Markdown pro úvodní stránku a /.well-known/ soubory. Jednou vymyšlené, dvakrát použité.

Naše projekty v produkci#

bhpslabs.com#

Tenhle web běží na TanStack Startu, TanStack Routeru, Reactu 19, Vite a Nitru, nasazený jako Node server v Dockeru. Je dvojjazyčný (čeština a angličtina) přes Paraglide a cesty mají tvar /$locale/....

Pár věcí, které stojí za zmínku:

• Blog (ano, i tenhle článek) se načítá z Markdown souborů přes vlastní Vite plugin, který je při buildu zvaliduje a převede do typovaných dat. Překlady článků spojuje složka, ne adresa.
• Poptávkový formulář odesílá data přes typovanou server funkci s validací a rate limitem:

export const sendAuditRequest = createServerFn({ method: 'POST' })
    .validator((value: unknown): SendInput => {
        if (!isInput(value)) throw new Error('Invalid input');
        return value;
    })
    .handler(async ({ data }): Promise<SendResult> => {
        if (!allow(getRequestIP({ xForwardedFor: true }) ?? 'unknown')) return { status: 'unavailable' };
        // … validace a odeslání e-mailu
    });

• Statické HTML, cache a komprese řešíme přes Nitro routeRules: písma a assety s dlouhou cache, HTML s revalidací, předkomprimované JS a CSS.

A výsledek? Lighthouse dává bhpslabs.com 100 / 100 / 100 / 100 ve všech čtyřech kategoriích (Performance, Accessibility, Best Practices, SEO) a v nové kategorii Agentic Browsing 3 / 3, která měří, jak dobře se na webu vyzná AI agent. To není zásluha jednoho triku. Je to součet věcí výše: prerender, SSR bez zbytečného JavaScriptu, metadata u každé route a server, do kterého si můžete přidat, co potřebujete. Start nám v ničem z toho nepřekážel.

udalist.app#

Udalist sbírá fotky a videa z akcí (svatby, oslavy, firemní eventy) do jedné sdílené galerie. Hosté naskenují QR kód a nahrávají přímo z prohlížeče v telefonu, bez aplikace a bez účtu. Je to naše vlajková loď a je tu víc aplikace než webu, takže je na něm vidět i druhá strana Startu:

• 33 souborů rout s layouty bez cesty: _public pro marketing, _guest pro hosty a _secure pro přihlášené. Každá skupina má svůj layout a svá pravidla, a adresa přitom zůstává čistá.
• TanStack Query žije v kontextu routeru, takže ho má k dispozici každý loader i beforeLoad. Data tahá z backendu v Kotlinu a v aplikaci ho používá kolem 25 souborů.
• TanStack Form obsluhuje devět formulářů, od kontaktu po nastavení zabezpečení akce.
• Sedm jazyků přes Paraglide, Sentry přes jeho oficiální SDK pro TanStack Start.
• A/B test úvodní stránky běží přes server funkci, která přečte cookie a nastaví hlavičky odpovědi.
• Cache pravidla pro Nitro jsou typovaná proti seznamu rout, který vygeneruje router. Když route přejmenujete nebo smažete, konfigurace cache přestane procházet kompilací:

import type { FileRouteTypes } from '../src/routeTree.gen';

type AppFullPath = FileRouteTypes['fullPaths'];

const MARKETING_PATHS_WITH_LONG_CACHE = [
    '/',
    '/pricing',
    '/faq',
    '/blog/',
    // …
] as const satisfies readonly AppFullPath[];

Překlep v adrese tak není tichá chyba v produkci, kdy stránka najednou přijde bez cache a bez bezpečnostních hlaviček. Je to červená čára v editoru. Přesně tohle mám na TanStacku rád.

Oba projekty mají schválně stejný základ. Jsme čtyřčlenný tým a nechceme udržovat dvě různé sestavy. Co vyřešíme na jednom, přeneseme na druhý.

Ekosystém je ta největší výhoda#

Start sám o sobě je skvělý, ale jeho skutečná síla je v tom, že není sám:

• TanStack Query pro serverová data a cache, standard, který znáte,
• TanStack Router s typovou bezpečností, jakou jinde nenajdete,
• TanStack Form pro typované formuláře bez ceremonií,
• TanStack Table a Virtual pro tabulky a dlouhé seznamy,
• a další: Store, Pacer, DB, AI, Devtools, Markdown…

Všechny knihovny mají stejnou filozofii: headless, typově bezpečné, framework-agnostické (React, Solid, Vue a další) a navržené tak, aby spolu dobře fungovaly. Když se naučíte jednu, ostatní vám přijdou povědomé. A když se rozhodnete jednu z nich nepoužít, nic se nerozbije.

Za ekosystémem navíc stojí silní partneři: Netlify, Vercel, Cloudflare, Railway, Render, Lovable, Clerk, WorkOS, Sentry, Prisma a další. To nejsou jen loga na webu. Jsou to SDK, šablony a integrace, které můžete použít hned.

Co není dokonalé#

Abych nepsal jen chvalozpěv: Nitro v3, na kterém Start v produkci běží, je stále v betě. Funguje nám bez problémů, ale je dobré to vědět. A některé pokročilé věci (třeba RSC) se pořád vyvíjejí, takže pokud na nich chcete stavět celou aplikaci, počítejte s tím.

Ani jedno pro nás nebyl důvod Start odložit.

Jak začít#

Pokud jste čekali na verzi 1.0, teď je ta chvíle:

pnpm create @tanstack/start@latest

Pak doporučuju dokumentaci Startu, a pokud migrujete z Next.js, má TanStack i průvodce migrací. A jak radí sám Tanner: pusťte na to klidně AI agenta. S aktuálními skills z balíčků, TypeScriptem a testy to zvládne překvapivě daleko.

Závěr#

TanStack Start 1.0 je pro mě potvrzení něčeho, co jsem věděl už dlouho. Framework nemusí diktovat, jak má vypadat celá aplikace. Může vám dát silné, typované a explicitní nástroje a nechat rozhodnutí na vás.

Na tomhle webu i na Udalistu to máme v produkci a všechno funguje, jak má. Kdo se mě zeptá, co dnes zvolit na frontend, dostane jasnou odpověď: TanStack Start. A k němu zbytek TanStacku.

Díky, Tannere, a díky celému týmu kolem TanStacku. A pokud řešíte, jestli a jak na Start přejít, ozvěte se nám. Rádi poradíme.

Všichni ostatní, pokračujte.

AI vám dnes napíše komponentu za minutu. Třeba i dvacet komponent za pět minut. Funguje to, testy projdou, všichni jsou spokojení. Pak otevřete pull request a vidíte, že jedna komponenta používá interface, druhá type, třetí má console.log zapomenutý uprostřed a čtvrtá importuje stejnou knihovnu třemi různými způsoby.

Žádná z těch věcí není chyba. Kód běží. Jenže codebase, ve které každý soubor vypadá, jako by ho psal někdo jiný, se špatně čte, špatně reviewuje a špatně udržuje. Té záplavě „nějak to funguje, ale nikdo to nesjednotil" se dnes říká AI slop. A každá hodina, kterou strávíte jeho úklidem, je hodina, kterou platíte.

Dobrá zpráva: dá se tomu předejít skoro zadarmo. Špatná zpráva: pokud to děláte pomalými nástroji, předejdete tomu jen napůl, protože je budete obcházet.

A důležitá věc na úvod: není to problém jen AI.

Není to jen o AI, jenom je to vidět víc#

Už v článku o pravidlu Interface vs. Type jsem psal o tom, co se stane, když se tým rozroste. Deset vývojářů, deset trochu jiných zvyklostí. Někdo je zvyklý na interface z Javy, někdo míchá oba přístupy a code review se promění v diskusi o mezerách místo o architektuře.

AI agent je v podstatě dalších deset vývojářů, kteří se nikdy nepotkali. Nezná vaše „nepsané pravidlo". Každá session začíná od nuly, model má naučené tisíce různých stylů a vybere si ten, který se mu zrovna hodí. A navíc píše rychleji než kdokoli z nás, takže nekonzistence rostou rychleji, než je stihne kdokoli zachytit.

Odpověď je stejná jako dřív, jen s vyšší naléhavostí: pravidla musí hlídat stroj, ne lidská paměť.

Pravidlo v promptu je prosba, pravidlo v linteru je zákon#

Dá se samozřejmě napsat do AGENTS.md nebo do systémového promptu: „Používej type místo interface, nepoužívej any, nenechávej console.log." Často to funguje. Ale je to jen prosba. Model na ni zapomene, jakmile se kontext zaplní, nebo si ji vyloží po svém.

Lint pravidlo funguje jinak. Buď projde, nebo neprojde. Nediskutuje se.

Moderní AI agenti navíc pracují ve smyčce:

1. napíšou kód,
2. spustí kontroly (testy, typy, lint),
3. přečtou chyby,
4. opraví je a jedou znovu.

Linter a formatter jsou přesně ta zpětná vazba, kterou tahle smyčka potřebuje. Agent se nemusí domýšlet, co máte rádi. Spustí jeden příkaz a dostane konkrétní odpověď: tady řádek 42, tohle pravidlo, tohle se nesmí.

Formatter navíc eliminuje celou kategorii šumu. Agent (ani člověk) nemusí řešit uvozovky, odsazení nebo čárky. Diff v pull requestu obsahuje jen skutečné změny a reviewer se soustředí na to, co dělá kód, ne na to, jak vypadá.

Krátká historie: ESLint a Prettier#

ESLint vznikl v roce 2013 a Prettier v roce 2017. Změnily JavaScript svět. ESLint hlídal kvalitu kódu (nepoužité proměnné, nebezpečné konstrukce, vlastní týmová pravidla), Prettier odstranil věčné spory o formátování tím, že rozhodl za všechny.

Dvojice ESLint + Prettier se stala standardem a po deset let fungovala skvěle. Mělo to ale jednu vlastnost, se kterou jsme se naučili žít: oba nástroje jsou napsané v JavaScriptu a běží v Node.js. Na malém projektu to nikdo nevnímá. Na velké codebase s TypeScriptem a type-aware pravidly se z lintu stane něco, co pouštíte „až na konec", protože trvá minuty.

Rust změnil pravidla hry#

Pak přišel projekt Oxc a s ním Oxlint (2023) a později Oxfmt. Obojí je napsané v Rustu, běží nativně a využívá všechna jádra procesoru.

Rozdíl v rychlosti není kosmetický. Jeden vývojář na Redditu popsal migraci svého firemního projektu (M3 MacBook Pro, medián ze tří běhů, přes 6 000 souborů):

• ESLint (single-thread, type-aware pravidla): ~2 min 27 s
• Oxlint (5 360 souborů, 134 pravidel, 11 vláken): ~1,3 s
• Prettier: ~13,9 s
• Oxfmt: ~2,1 s

Pozor, je to jeden konkrétní projekt s jednou konkrétní konfigurací a váš výsledek se bude lišit. Oficiální čísla z dokumentace Oxc jsou střízlivější: Oxfmt je zhruba 30× rychlejší než Prettier. Ale řád je všude stejný. Mluvíme o desítkách a stovkách násobků, ne o desítkách procent.

A tady je důležité, co se za poslední rok změnilo:

• Oxfmt je od února 2026 v betě a prochází 100 % konformitních testů Prettieru pro JavaScript a TypeScript. Zbylé rozdíly jsou známé chyby samotného Prettieru. Výstup se tedy neliší, jen je rychlejší.
• Type-aware linting je od července 2026 stabilní. Dělá ho tsgolint postavený na nativním TypeScriptu 7 a pokrývá 59 z 61 type-aware pravidel z typescript-eslint. To byla dlouho největší výmluva, proč zůstat u ESLintu.
• Oxlint dnes podporuje přes 800 pravidel z ESLint core a populárních pluginů (React, jsx-a11y, import, unicorn...) a umí spouštět i JS pluginy.

Rychlost jsou peníze#

Říkám to vždycky, i když to zní trochu suše: rychlost nástrojů je business argument.

Spočítejme si to na jednoduchém, ilustračním příkladu. Tým deseti vývojářů, každý spustí kontroly desetkrát denně (před commitem, před pushem, při opravách po CI). Při dvou a půl minutě čekání na jeden běh to dělá 10 × 10 × 2,5 min, tedy zhruba 4 hodiny denně a asi 80 hodin měsíčně strávených pohledem na terminál. S Oxlintem (1,3 s na běh) je to dohromady necelé dvě minuty denně.

A to jsme nezapočítali:

• CI/CD pipeline. Každá minuta v pipeline se platí (runnery) i čeká (vývojář). Rychlejší lint znamená rychlejší zpětnou vazbu na pull requestu a rychlejší release.
• Pre-commit hooky. Hook, který trvá 40 sekund, lidé začnou obcházet přes --no-verify. Hook, který trvá sekundu, nikdo nevypíná.
• Doručování. Rychlejší cyklus znamená, že klientům dříve doručíme featuru i opravu chyby. To je to, na co se zákazník ptá.

Kde do toho zapadá AI#

Tady se ta rychlost násobí. Vývojář spustí lint párkrát za den. AI agent ho pouští po každé iteraci, tedy klidně dvacetkrát za jeden úkol.

Pokud každý běh trvá dvě minuty, agent buď čeká (a vy čekáte s ním, případně platíte minuty běhu cloudového agenta), nebo, a to je horší, kontrolu začne přeskakovat. Pomalá zpětná vazba vede k tomu, že agent udělá víc práce naslepo a pak opravuje víc věcí najednou.

Co se týče tokenů, buďme přesní: samotné čekání tokeny nepálí. Pálí je počet iterací a velikost kontextu. Když agent dostane rychlou a přesnou zpětnou vazbu hned po každé změně, opraví chybu, dokud je malá. Když ji dostane až na konci, musí znovu číst větší kus kódu, rozplétat souvislosti a opravovat i věci, které mezitím postavil na špatném základu. Podle toho, jaký model používáte, to může být znát i na faktuře.

Výsledek: rychlý linter je pro AI agenta to, co rychlé testy pro člověka. Dokud trvají vteřiny, používá se. Jakmile trvají minuty, začne se kolem nich chodit.

Jak to máme nastavené my#

Nezůstaňme jen u teorie. Tenhle web běží na Oxlintu a Oxfmt. Konfigurace linteru vypadá takhle:

import { defineConfig } from 'oxlint';

export default defineConfig({
    plugins: ['import', 'unicorn', 'react', 'typescript', 'jsx-a11y'],
    categories: {
        correctness: 'warn',
    },
    rules: {
        'eslint/no-console': ['error', { allow: ['warn', 'error'] }],
        '@typescript-eslint/consistent-type-definitions': ['error', 'type'],
        '@typescript-eslint/no-explicit-any': 'error',
        '@typescript-eslint/no-unused-vars': 'error',
    },
});

Všimněte si prostředního řádku. Pravidlo consistent-type-definitions, kvůli kterému jsem kdysi psal vlastní ESLint plugin, je dnes jeden řádek konfigurace a běží v Oxlintu nativně. Stejně tak pravidla pro přístupnost (jsx-a11y), která si AI ráda vynechá.

A abychom nemuseli myslet na tři příkazy, máme jeden v package.json:

{
    "scripts": {
        "lint": "oxlint",
        "fmt": "oxfmt",
        "cq": "oxlint && oxfmt --check && tsc --noEmit"
    }
}

cq (code quality) pouští lint, kontrolu formátu a typy. Stejný příkaz běží v CI. Stejný příkaz říkáme agentovi. Do instrukcí pro agenty (AGENTS.md, CLAUDE.md, rules) stačí jedna věta:

Než práci označíš za hotovou, spusť `pnpm run cq` a oprav všechna zjištění.

Tím se z „doporučení" stává brána, kterou kód musí projít, ať ho psal člověk, nebo model.

Není to ještě 100 % (a stejně bych nesáhl po ničem jiném)#

Nechci tu psát reklamu, takže na rovinu: Oxlint a Oxfmt ještě nejsou 100% náhrada za ESLint a Prettier. Pár věcí, na které narazíte:

• Ne každé pravidlo existuje. Oxlint pokrývá přes 800 pravidel, ale nějaké speciální pravidlo z ESLint pluginu, na kterém závisíte, může chybět.
• Vlastní ESLint pluginy. Lokální pluginy se nemigrují automaticky, ale dají se ručně přidat do konfigurace přes jsPlugins. Oxlint umí většinu ESLint v9 API, ne úplně všechno.
• Prettier pluginy a méně obvyklé formáty. Oxfmt je v betě a podpora Prettier pluginů se teprve dotahuje. Pokud závisíte na přesném chování konkrétního pluginu, ověřte si to předem.
• Type-aware linting vyžaduje TypeScript 7. Na starší verzi je to jeden krok navíc.

Co s tím? Můj postoj je jednoduchý: dokud nepřijde něco lepšího, nesáhl bych po ničem jiném než po Oxlintu a Oxfmt. Ne proto, že jsou dokonalé, ale proto, že rozdíl v rychlosti je tak velký, že pár chybějících pravidel nebo drobných odchylek jde vyřešit, kdežto pomalý nástroj v pipeline nevyřešíte nikdy. Vývoj jde navíc rychle dopředu: Oxfmt prošel za pár měsíců od alfy k betě s plnou kompatibilitou na JS a TS a type-aware linting je stabilní.

Pokud vám opravdu nějaké pravidlo chybí, jde to přemostit tím, že Oxlint pustíte první a ESLint necháte jen pro to, co zbývá (oxlint && eslint, plugin eslint-plugin-oxlint vypne duplicity). Berte to ale jako dočasnou lávku, ne jako cílový stav.

Jak začít (za odpoledne)#

Migrace je dnes překvapivě bezbolestná.

Linter:

pnpm add -D oxlint
npx @oxlint/migrate

Formatter:

pnpm add -D oxfmt@latest
pnpm oxfmt --migrate=prettier
pnpm oxfmt

Hromadné přeformátování nechte jako samostatný commit a přidejte jeho hash do .git-blame-ignore-revs, aby git blame nepoukazoval na „kdo přeformátoval celý projekt". Potom aktualizujte CI a pre-commit hooky a nakonec napište příkaz do instrukcí pro AI agenty.

Závěr#

Ve světě, kde kód z velké části píše model, není konzistence luxus. Je to jediná věc, která udrží codebase čitelnou pro lidi i pro další AI agenty, kteří po vás přijdou.

Pravidla musí být automatická (nechceme na ně pořád myslet), vynucená (žádné „příště si dám pozor") a rychlá (jinak se jim všichni vyhnou). ESLint a Prettier nás tomu naučili. Oxlint a Oxfmt to dotáhly do stavu, kdy kontrola trvá vteřinu, ne minuty. A to se vyplatí, ať už platíte za čas vývojářů, za CI minuty, nebo za tokeny.

Pokud je váš lint dnes ten krok, který pouštíte „až na konec", zkuste ho přepnout. Stačí odpoledne. A pak se mi ozvěte, kolik sekund vám zbylo.

Před sedmi lety jsem stál uprostřed továrny – ruce špinavé od oleje, montérky plné prachu, kolem mě hluk strojů a v hlavě pocit, že můj život nikam nevede. Směny se táhly jedna za druhou, a když pršelo, sedl jsem na kolo a šlapal domů – promočený, unavený, s myšlenkou, že takhle to asi bude navždy. Nebyl jsem zoufalý, ale cítil jsem, že chci víc. Ne proto, že bych se považoval za lepšího než lidi kolem mě – ti byli poctiví, pracovití, stejně jako já. Nikdy jsem nebyl jedničkář ve škole, nebyl jsem nějaký výjimečný talent. Byl jsem obyčejný kluk, co chtěl v životě něco dokázat. Jednoho dne jsem se zastavil v dešti, podíval se na sebe – zašpiněný elektrikář na kole – a řekl si: „Tohle nechci dělat do konce života.“ Touha po změně mě přivedla k programování – k něčemu, o čem jsem nikdy nesnil a k čemu jsem neměl žádné předpoklady. Dnes, ve 26 letech, jsem front-end tech lead v Raynet CRM, jednom z nejlepších CRM systémů v Česku a na Slovensku. Nic mi nikdo nedal zadarmo – všechno, co mám, jsem si vydřel sám. Neměl jsem to lehké, stejně jako nikdo v továrně, a nechci, aby to znělo, že jsem něco víc. Jen jsem se rozhodl jít za svým cílem, i když jsem si na začátku vůbec nevěřil.

Začátky: Žádné předpoklady, žádná pomoc#

Nikdy jsem si nemyslel, že budu programátor. Jako dítě jsem nebyl ten kluk, co tráví hodiny u počítače nebo skládá roboty. Běhal jsem venku, hrál fotbal, bavil mě reálný svět – technologie mě míjely. Po škole jsem se stal elektrikářem, protože to bylo praktické a dostupné. Uměl jsem zapojit kabely, spravit zásuvku, ale o programování jsem nevěděl nic. Život v továrně byl rutina – vstávat, makat, domů, spát, a zase dokola. Lidi kolem mě byli skvělí, pracovití, a já jsem je respektoval. Nešlo o to být lepší než oni – jen jsem cítil, že chci něco jiného. Koupil jsem si starý notebook – takový ten, co vrčel jako traktor a po chvíli se přehříval – a začal hledat na internetu, co je to programování. Neměl jsem nikoho, kdo by mě nasměroval – žádného kamaráda ani známého v oboru. První večery byly chaos – seděl jsem po směně, oči mě pálily z únavy, a snažil jsem se pochopit, co znamená „Hello World“ v HTML. Připadalo mi to jako cizí svět. Nevěřil jsem si, ale řekl jsem si: „Když to zvládli jiní, zvládnu to taky.“ A tak jsem začal.

Disciplína jako jediný společník#

Každý den jsem si vyhradil čas. Po směně, když jsem přišel domů špinavý a vyčerpaný, jsem si řekl: „Aspoň hodinu.“ Někdy jsem vstával ve čtyři ráno, ještě za tmy, abych stihl tutoriál před prací. Bylo to, jako bych měl dvě zaměstnání – v továrně jsem šrouboval a opravoval, doma jsem se učil něco nového. Hledal jsem odpovědi na Google, procházel YouTube videa, četl fóra do noci. Když jsem poprvé pochopil CSS a viděl, jak se stránka mění podle mého kódu, cítil jsem naději. Pak přišel JavaScript – úplně jiný svět, hodiny jsem zíral na chyby v konzoli a nerozuměl, proč to nefunguje. Často jsem chtěl skončit. Měl jsem impostor syndrom – pocit, že jsem podvodník, co na to nemá. Ale motivace něčeho dosáhnout mě hnala dál. Chtěl jsem být hrdý na sebe – na to, že to zvládnu vlastními silami, že mi to nikdo nemůže vzít. Když se mi podařilo rozjet jednoduchou kalkulačku nebo animaci, říkal jsem si: „Možná na tom něco je.“ Disciplína mě držela nad vodou – i když jsem si nevěřil, nevzdal jsem to.

Cesta plná zklamání#

Po měsících učení jsem se rozhodl zkusit práci. Napsal jsem životopis – obyčejný, bez titulů, jen s pár větami o tom, co jsem zvládl sám. Rozeslal jsem ho – nejdřív deset, pak dvacet, nakonec asi sto. A co přišlo? Ticho. Občas e-mail: „Děkujeme, ale hledáme někoho s praxí.“ Nebo: „Bez školy to nejde.“ Jako junior s minulostí elektrikáře jsem byl neviditelný. Ty chvíle mě deptaly. Seděl jsem večer doma, zíral na další odmítnutí a ptal se sám sebe: „Proč to dělám?“ Impostor syndrom sílil – cítil jsem se jako podvodník, co si jen hraje na programátora. Jednou jsem seděl v kuchyni, venku lilo, a říkal si: „Možná jsem blázen.“ Chtěl jsem to vzdát, vrátit se k montérkám, k jistotě. Ale pak mě napadlo, co by to znamenalo – žádný pokrok, jen továrna. Chtěl jsem něco, na co budu moct být hrdý. Tak jsem se zvedl, otevřel další tutoriál, poslal další životopis. Po šesti měsících – plných odmítnutí a pochybností – mi někdo zavolal. „Máme pozici junior programátora v Pickering Interfaces v Třinci. Chcete to zkusit?“ Ten hovor změnil všechno.

První práce: Nechtěný projekt a mezinárodní tým#

Když jsem nastoupil do Pickering Interfaces v Třinci, dceřiné společnosti britského Pickeringu, cítil jsem, že se můj život posouvá. Poprvé jsem měl kolegy – a ne jen tak ledajaké. Pracoval jsem v mezinárodním týmu na projektu, který přesahoval hranice Česka. Po měsících osamělého učení to bylo osvobozující, ale ne jednoduché. Přišel jsem jako náhrada za programátora, který odešel, a zdědil jsem projekt, co nikdo nechtěl – zapomenutý kód, který nikdo nechtěl spravovat ani vyvíjet. Jako nováček jsem dostal to, co bývá zvykem – tu nejtěžší, nejméně oblíbenou práci. Ze začátku jsem nevěděl, kde začít. Impostor syndrom mě pronásledoval – bál jsem se, že selžu. Ale řekl jsem si: „Já jsem jiný. Naučím se to.“ Pustil jsem se do toho – učil jsem se za pochodu, řešil chyby, hledal cestu. Postupně jsem ten projekt zvládl, a dnes jsem za to rád. Nebyli na mě měkcí, hodili mě do hluboké vody, a to mě donutilo růst. Dokonce jsem za svou práci dostal sklenku na whisky od britské královny – maličkost, ale pro mě symbol, že tvrdá práce má smysl. Po dvou letech v Třinci jsem musel opustit rodné město a přestěhovat se do Ostravy – těžké rozhodnutí, ale věděl jsem, že mě čeká další výzva.

Růst v Raynet CRM: Od juniora k tech leadovi#

V Ostravě jsem nastoupil do Raynet CRM jako junior programátor. Začínal jsem odspoda, ale poprvé jsem měl kolegy a mentory, kteří mi pomohli, kdykoliv jsem potřeboval. Žádná otázka nebyla hloupá – jak jsem si řekl: „Ten, kdo se bojí zeptat, je trouba navždy; ten, kdo se nebojí, je trouba jen na pár minut.“ Ptát jsem se nebál. Po letech bez podpory to byla změna – měl jsem tým, co mě táhl dopředu. Mentoři mě učili psát lepší kód a přemýšlet jako programátor. Disciplína, kterou jsem si vybudoval, se spojila s jejich vedením, a já jsem rostl rychle. Za čtyři roky jsem se z juniora stal front-end tech lead – ve 26 letech! Dnes navrhuju řešení a pracuju na špičkovém CRM. Moji nadřízení mi důvěřují, můj názor má váhu, a já mám vliv na fungování týmu. Jsem hrdý – nejen za sebe, ale i za to, že můžu pomoci rodině a přátelům, kdykoliv mě potřebují. Práce hlavou je náročná, někdy mi chybí ta obyčejná práce rukama – šroubování, opravování, něco hmatatelného. Ale vím, že to, co dělám teď, má smysl. Před pár měsíci jsem napsal kus kódu, který teď programátoři po celém světě můžou využít – a využívají ho. Když to vidím, cítím, že má práce přesahuje můj stůl.

Kam dál: Vize a mentoring#

Když jsem byl elektrikář, nevěřil jsem, že ve 26 letech budu tech lead. Teď si říkám: „Uvidíme, kam mě cesta ještě zavede.“ Chci růst dál – v technologiích i v leadershipu. Sním o větším vlivu – třeba vést větší tým, podílet se na přelomových projektech, nebo zkusit podnikání v IT. Možná jednou vytvořím vlastní aplikaci, která pomůže lidem, jako Raynet pomáhá teď. Každý den se učím něco nového – ať je to framework, nebo jak motivovat tým. Teď jsem já mentorem pro své juniory v Raynetu, a to mě baví. Vidím v nich sebe – ty pochybnosti, ten strach, jestli na to mají. Pomáhám jim, jak jsem kdysi potřeboval pomoc já, a vidět jejich pokroky mě motivuje dál. Cesta mě naučila, že limity si stavíme sami – a já je stavět nechci.

Závěr: Ty na to taky máš#

Můj příběh není o talentu. Nebyl jsem génius, neměl jsem předpoklady, dlouho jsem neměl nikoho, kdo by mi pomohl. Nejsem jiný než lidi v továrně nebo kdokoli, kdo dělá práci, co ho nebaví. Nejsem lepší – jen jsem se rozhodl vystoupit z komfortní zóny, i když jsem si nevěřil. Na začátku jsem měl impostor syndrom, nevěřil jsem, že na to mám, chtěl jsem skončit. Ale nevzdal jsem to. Od továrny přes Pickering Interfaces v Třinci, kde jsem pracoval pro britskou firmu, až po Raynet CRM v Ostravě – z nuly na Tech leada ve 26 letech. Jsem hrdý, že to, co jsem dokázal, je moje, a že můžu podpořit rodinu a přátele. Lidé často nevystupují z komfortní zóny, myslí si, že na změnu nemají. Já jsem byl stejný. Ale chci vám říct: Máte na to. Nejlepší čas začít byl třeba před rokem – druhý nejlepší je teď. Nemusíte mít předpoklady – já jsem je neměl. Stačí začít, vydržet a nevzdát se. Já jsem to dokázal – a vy to zvládnete taky. Udělejte ten první krok. Stojí to za to.

Nebavíme se o jednotkách případů. Bavíme se o stovkách balíčků, které byly kompromitovány. Útočníci získali přístup k účtům maintainerů (často přes sociální inženýrství nebo uniklé tokeny) a do legitimních, hojně používaných knihoven propašovali škodlivý kód.

Některé z těchto balíčků měly miliony stažení týdně. Představte si to: v pondělí ráno přijdete do práce, spustíte npm install, a aniž byste cokoliv tušili, stahujete si do projektu malware, který krade vaše ENV proměnné nebo injectuje kryptominer do prohlížečů vašich uživatelů.

Je to děsivé. A upřímně – pokud spoléháte jen na štěstí, je to jen otázka času, kdy to trefí i vás.

Tři vrstvy manuální obrany#

První instinktivní reakce je: "Přestanu používat NPM!" To je sice hezká myšlenka, ale v moderním frontend vývoji asi tak reálná, jako chtít postavit mrakodrap jen pomocí kladiva a hřebíků. Bez ekosystému Reactu, TanStacku nebo Tailwindu se dnes neobejdeme.

Existují ale kroky, které dělám, abych riziko minimalizoval:

1. Minimalismus a Forkování#

Než přidám novou závislost, ptám se: "Opravdu potřebuji celou knihovnu na to, abych naformátoval datum?" Pokud je to malá utilita, raději si ji napíšu sám. Pokud je to složitější knihovna, která ale obsahuje spoustu balastu, často udělám fork. Vezmu si jen tu část kódu, kterou potřebuji, a vložím ji přímo do svého repozitáře. Tím odstřihnu pupeční šňůru od budoucích aktualizací (které mohou být infikované).

2. Zákaz skriptů (ignore-scripts)#

Většina útoků se spoléhá na tzv. postinstall skripty. To jsou příkazy, které se spustí automaticky hned po stažení balíčku. Útočníci je milují – je to ideální místo, kam schovat curl, který odešle vaše .env soubory na jejich server.

Obrana je jednoduchá. Do kořene projektu (k souboru package.json) přidejte soubor .npmrc s tímto obsahem:

ignore-scripts=true

Tím globálně zakážete spouštění těchto skriptů. Ano, občas to rozbije instalaci nějakého legitimního nástroje (třeba esbuild nebo cypress), ale to se dá vyřešit whitelistováním konkrétních balíčků. Bezpečnost za to stojí.

3. pnpm a verze, které už chvíli žijí#

npm stáhne balíček v minutě, kdy ho někdo publikuje. Útočník vydá verzi, vy v tu samou chvíli spustíte instalaci, a je to u vás.

pnpm od verze 12 to v základu nedělá. Má pravidlo minimumReleaseAge: stáhne jen verzi, která je na registry starší než 24 hodin. Počítá se to v minutách, výchozí hodnota je 1440 (jeden den). Většina těch napadených releasů se odhalí a z registry zmizí právě během prvních hodin. Den prodlevy vás od nich odřízne dřív, než si je stáhnete.

Mně je den málo. Chci verze staré 7 až 14 dní, které už chvíli žijí a nikdo je nestačil stáhnout jako malware. Nastaví se to v pnpm-workspace.yaml. Sedm dní je 10080 minut, čtrnáct je 20160:

# 7 dní. Když projekt může počkat dva týdny, dejte sem 20160.
minimumReleaseAge: 10080

Platí to i na tranzitivní závislosti, ne jen na to, co máte vypsané v package.json. Novější verzi si pořád můžete doinstalovat, až na ni přijde řada. Jen už to nebude ta, která vyšla před deseti minutami.

Automatizace: Když člověk nestačí#

Manuální kroky jsou fajn, ale mají jednu slabinu: mě. Já zapomínám. Já nemám čas každé ráno číst bezpečnostní reporty a kontrolovat, jestli verze lodash 4.17.21 není náhodou děravá.

Dlouho jsem hledal nástroj, který by mi hlídal záda. Potřeboval jsem něco, co:

1. Běží automaticky (CI/CD).
2. Zná databázi zranitelností (GitHub Security Advisories, OSV).
3. Nebude mě otravovat zbytečnými aktualizacemi, ale bude křičet, když jde o bezpečnost.

Vítězem se stal Renovate Bot.

Můj "Security-First" Config#

Renovate většina lidí zná jako nástroj, který automaticky zvedá verze balíčků. "Vyšla nová verze Reactu? Tady máš PR."

Já ho ale používám jinak. Na stabilních projektech nechci, aby mi bot "rozbíjel" aplikaci aktualizacemi minor verzí, které nepotřebuji. Chci, aby mlčel a ozval se pouze v případě, že moje aktuální verze obsahuje bezpečnostní díru.

Tohle je konfigurace, kterou aktuálně testuji a která mi dává klidné spaní:

{
    "$schema": "[https://docs.renovatebot.com/renovate-schema.json](https://docs.renovatebot.com/renovate-schema.json)",
    "extends": ["group:turboMonorepo", ":semanticCommits"],
    "timezone": "Europe/Prague",
    "prConcurrentLimit": 10,
    "prHourlyLimit": 0,
    "dependencyDashboard": true,
    "dependencyDashboardApproval": false,
    // Tady začíná magie: Zapínáme Security Alerts
    "vulnerabilityAlerts": {
        "enabled": true,
        "labels": ["security", "vulnerability"]
    },
    "osvVulnerabilityAlerts": true,
    "automerge": false,
    "rangeStrategy": "pin",
    "schedule": ["at any time"],
    // Pravidlo, které vypíná VŠECHNY aktualizace...
    "packageRules": [
        {
            "description": "Disable all non-security updates",
            "matchUpdateTypes": ["major", "minor", "patch", "pin", "digest", "lockFileMaintenance", "rollback", "bump", "replacement"],
            "enabled": false
        }
    ]
}

Jak to funguje?#

Všimněte si sekce packageRules. Ta explicitně říká: "Zakaž (enabled: false) všechny typy aktualizací (major, minor, patch...)."

Kdybych skončil tady, Renovate by nedělal nic. Ale protože mám nahoře zapnuté vulnerabilityAlerts a osvVulnerabilityAlerts, Renovate stále kontroluje databáze zranitelností.

Výsledek?

• Vyjde axios v1.8.0 (nová feature)? Ticho. Renovate mě neruší.
• Zjistí se, že axios v1.7.0 má bezpečnostní díru? ALARM. Renovate okamžitě vytvoří Pull Request s opravou na bezpečnou verzi a otaguje ho jako security.

Tento config stačí zapojit do GitHub/GitLab CI pipeline a nastavit spouštění jednou denně (nebo každou hodinu).

Díky tomu vím, že i když já spím, můj repozitář je porovnáván s nejnovějšími databázemi hrozeb. Není to 100% ochrana (ta neexistuje), ale je to mnohem lepší, než doufat, že se mi to vyhne.

Chaos při škálování týmu bez jasných pravidel#

Když jsem ve své firmě začal pracovat s TypeScriptem, náš tým byl malý – jen hrstka vývojářů. Měli jsme ústní dohodu, že se budeme držet type aliasů místo deklarací interface, protože nám připadaly předvídatelnější (více o tom později). Zpočátku to fungovalo skvěle. Byli jsme sladění, náš kód byl čistý a život byl fajn. Pak ale náš tým rychle vyrostl. Během roku jsme měli 10 vývojářů přispívajících do stejné codebase, a tehdy se věci zkomplikovaly.

Noví členové týmu si nebyli vždy vědomi našeho „nepsaného pravidla“. Někteří preferovali interface, protože jim to připadalo povědomější z jejich Java backgroundu. Jiní míchali oba přístupy, aniž by si toho vůbec všimli. Code reviews se změnily v nekonečné debaty o stylu spíše než o podstatě. Bylo jasné, že potřebujeme lepší způsob, jak vynutit konzistenci – něco automatizovaného, spolehlivého a škálovatelného. Takže jsem se rozhodl vyhrnout si rukávy a vytvořit vlastní ESLint plugin: eslint-plugin-interface-to-type. Ten by automaticky vynucoval použití type namísto interface napříč celou naší codebase a zachránil nás před námi samými.

Proč jsem si vybral type místo interface#

Než se ponoříme do technických detailů, pojďme si říct, proč jsem si vůbec vybral type místo interface. Na první pohled se mohou zdát zaměnitelné – oba definují tvary objektů, že? Ale je tu jemný rozdíl, který vás může ve větších projektech kousnout: Declaration Merging (slučování deklarací).

V TypeScriptu platí, že pokud deklarujete dvě definice interface se stejným názvem, automaticky se sloučí do jedné. Zde je rychlý příklad:

interface User {
    id: number;
}

interface User {
    name: string;
}

// TypeScript merges them into:
interface User {
    id: number;
    name: string;
}

Toto chování může být v některých případech užitečné, například při rozšiřování typů knihoven třetích stran. Ale v prostředí spolupráce je to recept na zmatek. Představte si dva vývojáře, kteří nevědomky deklarují konfliktní vlastnosti v oddělených souborech – je to chyba čekající na to, až se stane. Na druhou stranu, type aliasy se neslučují. Pokud se pokusíte deklarovat dva type aliasy se stejným názvem, TypeScript vyhodí chybu kompilace, což vás donutí vyřešit konflikt předem. Pro mě je tato předvídatelnost záchranou života.

Kromě slučování deklarací jsou type aliasy flexibilnější. Mohou reprezentovat uniony, průniky (intersections) a primitiva – věci, se kterými interface zápasí. I když interface má své místo (například když potřebujete rozšiřovat třídy), zjistil jsem, že type je bezpečnější výchozí volbou pro většinu našich případů použití.

Tvorba pravidla ESLint: Od chaosu ke konzistenci#

Teď, když jsem měl jasný důvod pro vynucení type, potřeboval jsem nástroj, který by to zajistil automaticky. Tady přichází na řadu můj ESLint plugin, eslint-plugin-interface-to-type. Chtěl jsem pravidlo, které by označilo jakoukoli deklaraci interface, navrhlo její nahrazení za type alias a dokonce poskytlo možnost automatické opravy (autofix) pro zefektivnění procesu.

Tvorba vlastního pravidla ESLint byla zpočátku trochu děsivá – nikdy předtím jsem žádné nepsal. Ale po nějakém průzkumu jsem tomu přišel na kloub. Plugin využívá AST (Abstract Syntax Tree) ESLintu k detekci deklarací interface a jejich transformaci na ekvivalentní type aliasy. Například toto:

interface User {
    id: number;
    name: string;
    role: 'admin' | 'user';
}

se označí a lze to automaticky opravit na:

type User = {
    id: number;
    name: string;
    role: 'admin' | 'user';
};

Nejtěžší částí bylo řešení okrajových případů – jako jsou deklarace interface, které rozšiřují (extend) jiné interfacy nebo mají složité generiky. Strávil jsem hodiny laděním pravidla, abych zajistil kompatibilitu a vyhnul se falešným pozitivům. Další výzvou byla implementace funkce automatické opravy. Možnost --fix v ESLintu vyžaduje poskytnutí přesných transformací, takže jsem musel pečlivě mapovat syntaxi interface na syntaxi type, aniž bych rozbil kód.

Jakmile byl plugin hotový, jeho nastavení bylo přímočaré. Stačí jej nainstalovat jako dev dependency:

npm install eslint-plugin-interface-to-type --save-dev

Poté jej přidejte do své konfigurace ESLint:

{
    "plugins": ["interface-to-type"],
    "rules": {
        "interface-to-type/prefer-type-over-interface": "error"
    }
}

Spusťte ESLint s --fix a on automaticky převede vaše deklarace interface na type aliasy. Hotovo!

Dopad na naše pracovní postupy: Méně bojování, více stavění#

Dopad tohoto pravidla na náš tým byl okamžitý. Dříve jsme trávili kusy code reviews dohadováním se o interface vs. type. Nyní za nás pravidlo vynucuje konzistenci a uvolňuje mentální prostor pro důležitější diskuze – jako je architektura nebo optimalizace výkonu.

Také nám to ušetřilo čas. Noví vývojáři už nepotřebovali dlouhou úvodní přednášku o našich preferencích stylu. Pravidlo to prostě vyřešilo. Code reviews se zrychlily, protože jsme už nehledali hnidy v syntaxi. Je to malá změna, ale dominový efekt byl obrovský.

Tipy pro vývojáře: Jak zařídit, aby to fungovalo pro váš tým#

Pokud vás tato myšlenka zaujala, zde je několik tipů, které vám pomohou vynutit používání type – nebo jakéhokoli standardu kódování – ve vašich projektech:

1. Nejprve pochopte své potřeby: Než začnete vynucovat type namísto interface, ujistěte se, že to odpovídá cílům vašeho týmu. Pokud se silně spoléháte na Declaration Merging nebo implementace tříd, interface může mít stále své místo. Pro nás type fungoval lépe v 99 % případů, takže dávalo smysl se na něm sjednotit.
2. Automatizujte pomocí nástrojů jako ESLint: Nespoléhejte na ústní dohody – ty se neškálují. Nástroje jako ESLint (nebo Prettier pro formátování) mohou konzistentně vynucovat pravidla v celém týmu. Psaní vlastního pravidla může znít zastrašujícím dojmem, ale je to skvělá zkušenost k učení a z dlouhodobého hlediska se vyplatí.
3. Podporujte zapojení týmu (Buy-In): Pokud zavádíte nový standard, získejte nejprve zpětnou vazbu od kolegů. Před zavedením jsem své pravidlo ESLint sdílel s týmem a jejich vstupy mi pomohly zachytit několik okrajových případů, které jsem přehlédl.

Vyzkoušejte to sami a dejte mi vědět!#

Přechod na type aliasy a jejich vynucení pomocí vlastního pravidla ESLint byl pro můj tým zásadní změnou. Náš kód se stal předvídatelnějším, recenze produktivnějšími a onboarding hladším. Pokud řešíte podobné problémy – nebo jen chcete experimentovat s přísnějšími standardy – doporučuji vám to vyzkoušet.

Začněte instalací eslint-plugin-interface-to-type a jeho spuštěním na vaší codebase. Uvidíte, jaký je to pocit mít konzistentní přístup k typům v TypeScriptu. Máte jiný pohled na interface vs. type? Nebo pravidlo odhalilo ve vašem projektu nějaké nečekané problémy?