Vite 8 Opsætning: 353% Flere Downloads i 2026

Før du deployer, bør du altid afprøve produktionsbygningen lokalt med npm run preview. Kommandoen starter en lille lokal server, der serverer dist/-mappen præcis, som en rigtig hosting-platform ville gøre, hvilket fanger fejl, som kun opstår i den optimerede build og ikke i dev-serveren, for eksempel forkerte relative stier eller manglende miljøvariabler. Skal appen deployes i en undermappe frem for domænets rod, sætter du base: '/min-mappe/' i vite.config.ts, ellers vil de genererede asset-stier pege forkert, og du ender med en hvid skærm i produktion.

Vite vs Webpack: downloads, ydelse og tal i 2026

Det er nyttigt at se, hvordan Vite-økosystemet reelt har flyttet sig, i tal, ikke kun i marketingsprog. Tabellen herunder er baseret på npm-vækstdata for ugen 8.-14. maj, sammenlignet mellem 2025 og 2026.

Pakke	Ugentlige downloads (2025)	Ugentlige downloads (2026)	Vækst år-over-år
vite	27,7 mio.	125,4 mio.	+353%
rolldown	50.000	28,8 mio.	+57.956%
vitest	ikke opgivet	45,1 mio.	+311%

Ifølge VoidZeros egen Serie A-meddelelse fra 29. oktober 2025 overhalede Vite Webpack i ugentlige downloads for første gang det år, samtidig med at Rolldown passerede 1 mio. ugentlige downloads. Det gør Vite til det mest brugte build-værktøj i sit segment målt på faktisk brug, ikke kun på omtale.

Det betyder ikke, at Webpack er forsvundet. Store, ældre kodebaser med årevis af tilpasset konfiguration skifter sjældent build-værktøj fra den ene dag til den anden, og Webpack forbliver et solidt valg til projekter, der allerede har investeret tungt i dets plugin-økosystem. Men for nye projekter, og for teams, der alligevel planlægger en større modernisering, peger både downloadtallene og retningen i økosystemet klart mod Vite som standardvalget i 2026.

Arkitektonisk er forskellen mellem de to værktøjer stadig markant, uafhængigt af downloadtal:

Egenskab	Vite 8	Webpack
Udviklingstilstand	Native ESM eller Rolldown fuld-bundle	Bundler hele appen før serveren starter
Bundler-motor	Rolldown (Rust) eller Rollup	webpack (JavaScript)
Konfiguration	vite.config.ts, ofte under 30 linjer	webpack.config.js, ofte flere hundrede linjer
Plugin-kompatibilitet	Rollup-plugin-API	Eget plugin- og loader-system
Indbygget test-runner	Vitest, delt konfiguration med Vite	Kræver separat opsætning, fx Jest

Faldgruber og fejlfinding du bør kende

De fleste problemer med Vite opstår i overgangen fra et andet build-værktøj eller ved uklarhed om, hvad der kører hvor. Her er de mest almindelige faldgruber, efterfulgt af en fejlfindings-oversigt.

Kommer du fra Create React App eller en ældre Webpack-opsætning, er den største omstilling typisk ikke selve kommandoerne, men de vante mønstre, du har med dig. Miljøvariabler, absolutte imports og statiske filer virker alle en smule anderledes i Vite, og de fleste fejl herunder opstår, fordi et gammelt vanemønster bliver bragt videre ind i et nyt projekt uden justering.

At bruge process.env i stedet for import.meta.env. Vite er ikke Node.js, og process findes ikke i browseren som standard. Brug altid import.meta.env til miljøvariabler i klient-kode.
At glemme VITE_-præfikset. En variabel som API_KEY i din .env-fil bliver aldrig eksponeret til klienten, uanset hvor mange gange du genstarter serveren. Den skal hedde VITE_API_KEY.
At placere store filer forkert. Filer i public/ bliver kopieret som de er, uden hash eller optimering. Statiske assets, der skal cache-busted, hører til i src/assets/ og skal importeres.
At antage, at aliaser i vite.config.ts også virker i tsconfig.json automatisk. De to filer deler ikke konfiguration. Et alias skal defineres begge steder.
At blande CommonJS og ESM uden at forstå konsekvensen. Nogle ældre npm-pakker er skrevet i ren CommonJS og kan kræve optimizeDeps-justeringer eller et interop-plugin for at fungere med Vites ESM-først-tilgang.

Problem	Sandsynlig årsag	Løsning
“process is not defined” i browserkonsollen	Kode bruger process.env i klient-side kode	Erstat med import.meta.env og VITE_-præfiks
Miljøvariabel er undefined i appen	Manglende VITE_-præfiks eller forkert .env-fil indlæst	Tjek præfiks og kør vite –mode for at bekræfte det aktive miljø
TypeScript klager over “@/”-imports	paths mangler i tsconfig.json	Tilføj samme alias i compilerOptions.paths
HMR virker ikke, hele siden genindlæses	Komponenten eksporterer ikke korrekt, eller filen blander flere eksporttyper	Sørg for én default export pr. komponentfil
“Failed to resolve import” for en npm-pakke	Pakken er ren CommonJS og indekseres forkert	Tilføj pakken til optimizeDeps.include i vite.config.ts
Build fejler, men dev-server virker fint	Statisk analyse i build finder kode-stier, dev-tilstand ikke rammer	Kør npm run build lokalt tidligt og ofte, ikke kun i CI
CSS mangler i produktion, men virker i dev	Dynamisk importerede stylesheets bliver ikke fanget af build-analysen	Importer CSS statisk øverst i komponentfilen
Port 5173 er allerede optaget	En anden Vite-instans kører i baggrunden	Sæt server.port i konfigurationen eller luk den anden proces
Plugin-rækkefølge giver uventet output	Et plugin kører før et andet, det er afhængigt af	Omarranger plugins-arrayet efter dokumentationens anbefaling

Går du i stå med et problem, der ikke står på listen, er den mest effektive fremgangsmåde at isolere, om fejlen opstår i dev-serveren eller i den byggede version. Kør npm run build lokalt og se, om fejlen dukker op der, før du fejlfinder i selve appkoden. Vite-teamet vedligeholder desuden en aktiv fejlrapportering på GitHub, hvor en stor del af de mest almindelige problemer allerede er beskrevet med løsning, ofte hurtigere at slå op end at fejlsøge fra bunden selv.

Avancerede tips og det komplette projekt

Når det grundlæggende sidder fast, er der en række justeringer, der løfter et Vite-projekt fra “det virker” til produktionsklart.

De fleste af tipsene herunder bliver først relevante, når projektet vokser forbi et par håndfulde komponenter. Det er fristende at optimere fra dag ét, men den bedre rækkefølge er at få den grundlæggende opsætning til at fungere først, målt via npm run build og en gennemgang af den genererede dist/-mappe, og først derefter gå videre til finjustering af chunks, workers og monorepo-opsætning.

Manuel chunk-splitting: brug build.rollupOptions.output.manualChunks til at adskille store afhængigheder som React eller chart-biblioteker i egne filer, så browseren kan cache dem separat fra din egen appkode, for eksempel manualChunks: { react: ['react', 'react-dom'] }. Det betyder, at en bruger, der besøger appen igen efter en ny udgivelse, kun skal downloade den ændrede appkode, ikke hele React-biblioteket på ny.
Forudindlæsning af moduler: Vite genererer automatisk modulepreload-tags for kritiske moduler, men du kan finjustere det med build.modulePreload-indstillinger, hvis du har komplekse routing-opsætninger.
Worker-support: importer en fil med ?worker-suffikset for automatisk at få den bundlet som en Web Worker, uden manuel opsætning af separate build-steps.
Monorepo-kompatibilitet: i et monorepo med flere pakker skal du sætte resolve.preserveSymlinks korrekt, så Vite finder lokale workspace-pakker uden at duplikere afhængigheder.
CI-cache: cache node_modules/.vite mellem CI-kørsler for at genbruge den forudoptimerede afhængighedscache og spare byggetid.

Sætter du alle trinene i denne guide sammen, ender du med et komplet, fungerende projekt: et React- og TypeScript-scaffold oprettet med npm create vite@latest, en tilpasset vite.config.ts med path-alias, proxy og build-indstillinger, Sass- og CSS Modules-understøttede stylesheets, miljøvariabler adskilt mellem udvikling og produktion via .env-filer, et Vitest-testsuite med dækningsrapportering, der deler konfiguration med resten af appen, samt en dist/-mappe klar til deploy på enhver statisk hosting-platform. Det er præcis den samme struktur, som ligger bag langt de fleste nye frontend-projekter, der startes i 2026.

Vil du udvide projektet videre herfra, er de naturlige næste skridt at tilføje en router (React Router eller TanStack Router til React-projekter), et state-management-bibliotek, hvis appen vokser i kompleksitet, og en CI-pipeline, der kører npm run build og npm run test på hver pull request, før kode når hovedgrenen. Ingen af de trin kræver, at du ændrer noget grundlæggende i Vite-opsætningen, du bygger blot videre oven på det fundament, du allerede har lagt.

Kort sagt handler skiftet til Vite mindre om at lære en helt ny disciplin og mere om at fjerne friktionen mellem at skrive kode og se den virke. De tolv trin i denne guide, fra installation over konfiguration og test til produktion, dækker det, de fleste teams reelt bruger i deres daglige arbejde. Resten, som avancerede build-optimeringer eller specialiserede plugins, kan du tilføje løbende, i takt med at projektet vokser og kravene bliver tydeligere.

Ofte stillede spørgsmål

Er Vite gratis at bruge?
Ja. Vite er open source under MIT-licens, og hele værktøjskæden omkring det, inklusive Rolldown, Vitest og Oxc, er også open source-projekter fra VoidZero. Der er ingen betalt tier eller licensnøgle involveret, uanset om projektet er privat, kommercielt eller open source.

Skal jeg opgradere fra Vite 7 til Vite 8 med det samme?
Ikke nødvendigvis. Vite 7 blev annonceret 24. juni 2025 og er stadig en fungerende, understøttet udgave. Opgrader, når du har tid til at teste build-output grundigt, især hvis projektet har mange tredjeparts-plugins, og læs altid ændringsloggen igennem for brudte funktioner, før du opgraderer et produktionsprojekt.

Kan jeg bruge Vite uden React, Vue eller Svelte?
Ja. Vite fungerer fint med almindelig vanilla JavaScript eller TypeScript, uden noget framework-plugin overhovedet. Vælg blot “Vanilla” i opsætningsguiden.

Hvad er forskellen på Rollup og Rolldown?
Rollup er den originale JavaScript-baserede bundler, som Vite historisk har brugt til produktionsbygninger. Rolldown er en Rust-baseret bundler fra samme hold, designet som en drop-in erstatning med samme plugin-API, men hurtigere udførelse.

Virker Vite med ældre npm-pakker, der ikke er ESM?
For det meste ja. Vite konverterer CommonJS-afhængigheder automatisk under forudoptimeringen. I sjældne tilfælde med kompleks pakkestruktur, hvor en pakke selv indlæser andre moduler dynamisk, skal du tilføje pakken manuelt til optimizeDeps.include eller i værste fald finde et moderne alternativ, der publiceres som ESM.

Kan jeg bruge Vite til et backend-projekt?
Vite er primært et frontend-værktøj, men Vite-teamet arbejder også med Server-Side Rendering-mønstre, som mange meta-frameworks bygger videre på. Til rene backend-API’er uden nogen browserkomponent er Vite ikke det rette valg.

Er Vitest et krav, hvis jeg bruger Vite?
Nej. Vitest er valgfrit, men fordelen ved at bruge det er, at det genbruger samme konfiguration, plugins og alias-opsætning som resten af projektet, så du undgår at vedligeholde to parallelle build-opsætninger.

Hvor finder jeg officiel dokumentation, hvis jeg går i stå?
Start med Vites officielle guide, som dækker konfiguration, plugins og deploy i detaljer, og GitHub-repositoriet, hvor du kan søge i issues, hvis du støder på en fejl, andre allerede har løst.

Vite har overhalet Webpack i ugentlige downloads på npm, og den nyeste Vite 8-udgivelse fra marts 2026 skifter motoren under motorhjelmen til Rolldown, en bundler skrevet i Rust. Hvis du bygger et nyt frontend-projekt i 2026, uanset om det er React, Vue eller Svelte, møder du sandsynligvis Vite som standardvalg. Denne guide viser dig, trin for trin, hvordan du opsætter et fuldt Vite-projekt fra bunden, konfigurerer det korrekt, tester det og sender det i produktion.

Du behøver ikke have brugt Vite før. Guiden er skrevet til udviklere, der kommer fra Create React App, Webpack eller et helt nyt projekt, og som vil forstå både kommandoerne og begrundelsen bag dem. Undervejs bygger vi et komplet React- og TypeScript-projekt med tests, miljøvariabler og en produktionsklar build, så du ender med noget, du reelt kan genbruge i dit eget arbejde, ikke bare et legetøjseksempel.

Hvad er Vite, og hvorfor er det relevant i 2026

Vite (udtales “veet”, fransk for “hurtig”) er et build-værktøj skabt af Evan You, manden bag Vue.js. Værktøjet startede som en løsning på et konkret problem: gamle bundlere som Webpack skulle pakke hele appen sammen, før udvikleren overhovedet kunne se en ændring i browseren. Vite vender det om. Under udvikling bruger værktøjet browserens indbyggede ES-moduler, så kun de filer, du rent faktisk redigerer, genindlæses.

Det, der gør 2026 til et vendepunkt, er Vite 8.0, udgivet 12. marts 2026. Med den udgivelse bliver Rolldown, en Rust-baseret bundler, en fast del af Vite selv, ikke længere en separat afprøvning. Ifølge det officielle Vite-team blev Rolldown “feature-complete” nok under betaperioden til at drive en ny fuld-bundle dev-tilstand, som nu kører side om side med den klassiske no-bundle-tilstand. Det betyder i praksis, at både udviklingsserveren og produktionsbygningen kan bruge samme motor.

Tallene bag den udvikling er svære at ignorere. En analyse af npm-pakker med hurtigst vækst viser, at vite-pakken gik fra 27,7 mio. ugentlige downloads i uge 8.-14. maj 2025 til 125,4 mio. i samme uge i 2026, en stigning på 353%. Selve rolldown-pakken voksede fra 50.000 til 28,8 mio. ugentlige downloads i samme periode. Bag udviklingen står firmaet VoidZero, grundlagt af Evan You, som ifølge deres egen meddelelse fra 29. oktober 2025 hentede 12,5 mio. dollar i en Serie A-runde ledet af Accel og Peak XV Partners, efter en tidligere seed-runde på 4,6 mio. dollar i 2024. Missionen er en samlet, open source-værktøjskæde bestående af Oxc (parser), Rolldown (bundler), Vitest (test-runner) og Vite selv.

For dig som udvikler betyder det hele, at Vite ikke bare er endnu et build-værktøj, det er blevet den fælles standard, som store dele af det moderne JavaScript-økosystem bygger videre på.

Vite blev første gang udgivet af Evan You i 2020 som et sideprojekt, mens han ledte efter en hurtigere måde at udvikle Vue-komponenter på. Løsningen var enkel, men effektiv: i stedet for at forudkompilere hele applikationen, lader Vite browseren selv hente moduler via native ES-imports, mens en let dev-server oversætter enkeltfiler on-demand med esbuild eller, i dag, Rolldown. Resultatet er en opstartstid, der forbliver nogenlunde konstant, uanset om projektet har 50 eller 5.000 filer, fordi serveren aldrig skal analysere hele afhængighedstræet på forhånd.

Den samme arkitektur bruges i dag som standard build-værktøj i flere populære meta-frameworks, blandt andet SvelteKit og Astro, hvilket betyder, at selv udviklere, der aldrig selv har skrevet en linje Vite-konfiguration, kører værktøjet under motorhjelmen hver dag.

Det er værd at forstå, hvorfor der overhovedet er behov for tre forskellige transformationsmotorer over tid. esbuild, skrevet i Go, var det første store spring i hastighed og blev brugt til at forudoptimere afhængigheder og transformere TypeScript under udvikling. SWC, skrevet i Rust, tilbød en lignende hastighedsgevinst og bruges stadig i visse React-plugins til Fast Refresh. Rolldown går et skridt videre ved ikke kun at transformere filer enkeltvis, men også selv at samle det færdige bundle, med samme plugin-API som Rollup, så eksisterende plugins fortsætter med at virke uden ændringer. Det er den detalje, der gør migrationen til Vite 8 relativt smertefri for de fleste projekter.

Forudsætninger: værktøjer og versioner du skal bruge

Før du går i gang, skal følgende være på plads. Guiden tager cirka 40-45 minutter at gennemføre, hvis du følger trinene i rækkefølge.

Node.js: en aktuel LTS-udgave anbefales (20.x eller nyere). Tjek din version med node -v.
Pakkehåndtering: npm følger med Node.js, men pnpm eller yarn virker lige så godt til denne guide.
Editor: VS Code eller et andet moderne editor-miljø med TypeScript-understøttelse.
Terminaladgang: macOS Terminal, Linux-shell eller Windows Terminal/PowerShell.
Git: valgfrit, men praktisk hvis du vil versionsstyre projektet undervejs.
Grundlæggende JavaScript- eller TypeScript-kendskab: guiden forudsætter, at du kan læse almindelig JS/TS-kode.
Editor-udvidelser (valgfrit): ESLint- og Prettier-udvidelser til VS Code gør fejl synlige, mens du skriver, og hvis du arbejder med Vue, er Volar-udvidelsen afgørende for korrekt typetjek i .vue-filer.

Du behøver ikke kende Rolldown eller Rust for at følge denne guide. Vite skjuler bundleren bag et almindeligt kommandolinje-interface, så du interagerer aldrig direkte med den, medmindre du selv vælger det.

Diskplads er sjældent et problem, et tomt Vite-projekt fylder typisk under 200 MB inklusive node_modules, men afhænger af hvor mange afhængigheder du tilføjer undervejs. Vite virker på macOS, Linux og Windows, og selve dev-serveren kræver blot en moderne browser med understøttelse af native ES-moduler, hvilket dækker alle gængse browserversioner fra de seneste år.

Trin 1-2: Installer Node.js og opret dit Vite-projekt

Har du ikke Node.js installeret, henter du det fra det officielle Node-projekt og vælger LTS-udgaven til dit operativsystem. Når installationen er færdig, bekræfter du den:

node -v
npm -v

Med Node.js på plads opretter du et nyt Vite-projekt. Kommandoen nedenfor starter en interaktiv guide, hvor du vælger framework og variant (JavaScript eller TypeScript). Vi bruger React med TypeScript som eksempel gennem resten af artiklen, men de samme trin gælder for Vue, Svelte, Preact og Lit.

npm create vite@latest mit-projekt -- --template react-ts
cd mit-projekt
npm install
npm run dev

Bruger du pnpm i stedet, erstatter du blot npm create med pnpm create, og npm install med pnpm install. Kommandoen scaffolder et komplet projekt med konfigurationsfiler, en simpel startside og en dev-server, der er klar til brug med det samme.

Springer du --template-flaget over, får du i stedet en interaktiv menu, hvor du kan vælge mellem de officielle skabeloner: vanilla, vue, react, preact, lit, svelte, solid og qwik, hver med en variant til både JavaScript og TypeScript. Det er en god måde at udforske mulighederne på, hvis du er i tvivl, men i et automatiseret script eller en CI-pipeline er det bedre at angive skabelonen direkte, som vi gør ovenfor, så opsætningen er forudsigelig hver gang.

Kommandoen opretter kun filerne. Den installerer ikke automatisk afhængigheder, derfor er npm install-trinet nødvendigt, før du kan køre npm run dev. Glemmer du det trin, får du en fejl om manglende moduler, allerede før serveren overhovedet starter.

Valget mellem npm, pnpm og yarn påvirker ikke selve Vite-opsætningen, men det er værd at kende forskellen. pnpm bruger et delt, indholdsadresseret lager på tværs af projekter på din maskine, hvilket typisk sparer betydelig diskplads, hvis du arbejder på flere Vite-projekter samtidig, og håndhæver strengere adgang til afhængigheder, så en pakke ikke ved et uheld kan bruge en anden pakkes transitiv afhængighed. Yarn Berry tilbyder lignende fordele med sit Plug’n’Play-system. Til denne guide er forskellen kosmetisk, men vælger du pnpm i et rigtigt projekt, er det værd at vide, at nogle ældre plugins forudsætter en flad node_modules-struktur og kan kræve en .npmrc-indstilling som shamefully-hoist=true for at fungere korrekt.

Trin 3-4: Projektstruktur, dev-server og Hot Module Replacement

Efter oprettelsen ser mappestrukturen sådan ud:

mit-projekt/
├── index.html
├── package.json
├── vite.config.ts
├── tsconfig.json
├── public/
│   └── vite.svg
└── src/
    ├── main.tsx
    ├── App.tsx
    ├── App.css
    └── assets/
        └── react.svg

Læg mærke til, at index.html ligger i roden, ikke i public/. Det er en bevidst designbeslutning i Vite: HTML-filen er indgangspunktet, og Vite behandler den som en del af modulgrafen, så du kan referere direkte til src/main.tsx med et almindeligt script type="module"-tag.

Kør npm run dev, og du får en output som denne:

  VITE v8.0.2  ready in 214 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

Den lave opstartstid er ikke tilfældig. Fordi Vite ikke bundler hele appen på forhånd i klassisk tilstand, starter serveren nærmest øjeblikkeligt, uanset hvor stort projektet er. Når du redigerer en komponent og gemmer filen, opdaterer Hot Module Replacement (HMR) kun den ændrede modul i browseren, uden at hele siden genindlæses og uden at du mister app-tilstand som formularfelter eller åbne faner. Det er den funktion, de fleste udviklere fremhæver som den største daglige forskel fra ældre værktøjer.

Teknisk sker det ved, at browseren beder om hver fil via et almindeligt import-kald, og Vites dev-server svarer med den transformerede version af netop den fil. Ændrer du App.tsx, sender serveren kun en opdateret version af den fil tilbage over en WebSocket-forbindelse, resten af applikationen rører den slet ikke. I den nye fuld-bundle-tilstand fra Rolldown fungerer det lidt anderledes, her forudbygges en større del af grafen, men opdateringerne under udvikling er stadig inkrementelle og målrettede.

Trin 5: Konfigurer vite.config.ts

Standardopsætningen virker fint til et lille projekt, men de fleste rigtige projekter har brug for tilpasninger, som stier, porte eller build-indstillinger. Alt det samler du i vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'node:path'

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  server: {
    port: 5173,
    open: true,
    proxy: {
      '/api': 'http://localhost:4000',
    },
  },
  build: {
    outDir: 'dist',
    sourcemap: true,
  },
})

Alias-opsætningen ovenfor betyder, at du kan skrive import Button from '@/components/Button' i stedet for lange relative stier som ../../../components/Button. Husk, at TypeScript ikke automatisk kender til aliaset, du skal også registrere det i tsconfig.json under paths, ellers klager typetjekkeren, selv om koden kører fint i browseren.

server.proxy-indstillingen ovenfor er nyttig, hvis din backend kører på en anden port under udvikling. Alle kald til /api/... fra frontenden bliver sendt videre til backend-serveren, så du undgår CORS-fejl i udviklingsmiljøet uden at skulle ændre noget i din faktiske applikationskode. Har du brug for forskellige indstillinger i udvikling og produktion, kan du erstatte det statiske objekt med en funktion, der modtager { mode } og returnerer den relevante konfiguration for hvert miljø.

Trin 6: TypeScript, path aliases og strict mode

Vælger du en TypeScript-skabelon, får du en fungerende tsconfig.json med det samme. Men to indstillinger er værd at kigge nærmere på, før du skriver rigtig kode.

Strict mode fra dag ét

Skabelonerne sætter typisk "strict": true som standard. Lad den indstilling stå. Det er langt sværere at aktivere streng typetjek på et halvfærdigt projekt end at starte med den slået til. Strict mode fanger blandt andet implicit any, null-referencer og manglende returtyper, allerede mens du skriver koden.

Path aliases i tsconfig.json

For at aliaset fra forrige trin virker i editoren, skal du tilføje følgende til compilerOptions:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

Uden den ændring vil koden bygge fint, fordi Vite selv løser aliaset under bygning, men VS Code vil vise røde streger under dine imports, og typetjek via tsc --noEmit i CI-pipelinen vil fejle.

Et andet punkt, mange overser, er filen vite-env.d.ts, som scaffoldingen opretter automatisk. Den indeholder en enkelt reference til Vites klienttyper og sikrer, at TypeScript kender til ting som import.meta.env og .svg-imports. Slet aldrig den fil, uden at forstå konsekvensen, det er her typerne til miljøvariabler og statiske assets kommer fra. Sæt derudover "isolatedModules": true i tsconfig.json, hvis den ikke allerede er sat, da Vite transformerer hver fil for sig og ikke kan håndtere visse TypeScript-funktioner, der kræver kendskab til hele projektet på tværs af filer.

Relateret til det er indstillingen verbatimModuleSyntax, som nyere TypeScript-skabeloner slår til som standard. Den tvinger dig til eksplicit at markere type-only imports med nøgleordet type, for eksempel import type { User } from './types', i stedet for at blande almindelige og type-only imports i samme linje. Det lyder som en detalje, men det er præcis den slags forskel, der gør, at Vites filbaserede transformation kan holde sig hurtig: kompilatoren behøver aldrig analysere hele projektet for at afgøre, om en import kun findes for typernes skyld.

Trin 7: CSS, Sass og statiske filer

Vite understøtter almindelig CSS uden yderligere opsætning. Importerer du en .css-fil direkte i en komponent, indsætter Vite den automatisk i siden under udvikling og samler den i én optimeret fil ved bygning. Vil du bruge Sass, Less eller Stylus, installerer du blot den relevante pakke:

npm install -D sass

Herefter kan du omdøbe filer til .scss og importere dem direkte, uden ekstra konfiguration i vite.config.ts. Vite registrerer filendelsen og sender indholdet gennem det rigtige forbehandlings-værktøj automatisk.

Statiske filer, som billeder, fonte og ikoner, placerer du i public/, hvis de skal serveres uændret fra roden af sitet (for eksempel favicon.ico), eller i src/assets/, hvis du vil importere dem direkte i komponenter og lade Vite hash filnavnet til cache-busting ved bygning. Forskellen er vigtig: filer i public/ bliver aldrig behandlet eller omdøbt, mens filer i src/assets/ bliver en del af modulgrafen og optimeret sammen med resten af koden.

Vite understøtter også CSS Modules ud af boksen, uden ekstra pakker. Navngiv filen Button.module.css, og Vite genererer automatisk unikke klassenavne, så stilarter i én komponent ikke kolliderer med en anden komponents klasser. Har du brug for PostCSS-plugins, som autoprefixer eller Tailwind, opretter du blot en postcss.config.js i projektroden, Vite finder og bruger den automatisk, uden at du skal registrere noget i vite.config.ts.

Bruger du Tailwind CSS, er den anbefalede vej i dag et dedikeret Vite-plugin (@tailwindcss/vite) i stedet for den ældre PostCSS-baserede opsætning. Det tilføjes til plugins-arrayet som ethvert andet plugin og giver hurtigere genkompilering af utility-klasser under udvikling, fordi Tailwind da kan hægte sig direkte på Vites modulgraf i stedet for at køre som et separat PostCSS-lag på hver eneste filændring.

Trin 8: Plugins til React, Vue og Svelte

Vite i sig selv er framework-agnostisk. Understøttelsen af specifikke frameworks kommer via officielle plugins, som du allerede har fået med, hvis du valgte en skabelon i trin 2. De mest brugte er:

@vitejs/plugin-react: bruger esbuild eller SWC til at transformere JSX og understøtte Fast Refresh, så React-komponenter opdateres uden at miste state.
@vitejs/plugin-vue: understøtter Vue Single-File Components (.vue-filer) med fuld HMR-integration.
@sveltejs/vite-plugin-svelte: kompilerer Svelte-komponenter og driver SvelteKit under motorhjelmen.

Fordi Vites plugin-API er kompatibel med Rollup-plugins, kan du derudover installere hundredvis af community-plugins til ting som PWA-understøttelse, billedoptimering, bundle-analyse eller automatisk import af komponenter. Vil du tilføje et plugin, importerer du det og tilføjer det til plugins-arrayet i vite.config.ts, i den rækkefølge, du vil have det udført.

En vigtig detalje: rækkefølgen i plugin-arrayet betyder noget. Nogle plugins forventer at køre før andre (for eksempel skal et plugin, der transformerer filtyper, ofte stå før et plugin, der analyserer den transformerede kode). Læs altid plugin-dokumentationen for anbefalet placering, før du blot tilføjer det sidst på listen.

To community-plugins er værd at kende fra start. vite-plugin-pwa gør det muligt at gøre appen installerbar og offline-tilgængelig uden at skrive en service worker fra bunden, og vite-imagetools lader dig transformere og optimere billeder direkte via import-forespørgsler, for eksempel ved at bede om en mindre eller webp-konverteret udgave af et billede i selve import-linjen. Begge installeres som almindelige dev-afhængigheder og tilføjes til plugins-arrayet på samme måde som de officielle framework-plugins.

Skal appen understøtte ældre browsere, der ikke forstår moderne JavaScript-syntaks, findes der et officielt plugin til netop det formål: @vitejs/plugin-legacy. Det genererer et ekstra build-lag med transpileret kode og polyfills, som ældre browsere indlæser, mens moderne browsere fortsat får den lette, native ESM-version. Det er en løsning, du typisk kun har brug for i virksomhedskontekster med krav om understøttelse af browsere, mange år bagud, ikke noget et nyt projekt behøver som standard.

Trin 9: Miljøvariabler med .env-filer

Vite læser miljøvariabler fra .env-filer i projektroden og eksponerer dem i din kode via import.meta.env. Af sikkerhedsårsager bliver kun variabler, der starter med præfikset VITE_, sendt med til klient-koden. Alt andet holdes tilbage på build-tidspunktet, så du ikke ved et uheld lækker server-hemmeligheder til browseren.

# .env.local
VITE_API_URL=https://api.mitfirma.dk
VITE_APP_NAME="Mit Projekt"

const apiUrl = import.meta.env.VITE_API_URL
console.log(import.meta.env.MODE) // "development" eller "production"

Du kan lave miljøspecifikke filer som .env.production eller .env.staging og køre Vite med et bestemt mode via --mode staging. Læg .env.local i din .gitignore, så personlige nøgler og lokale endpoints aldrig ender i versionsstyringen.

Rækkefølgen, Vite indlæser filerne i, betyder noget, når flere filer definerer den samme variabel. Prioriteten går fra .env.[mode].local øverst, derefter .env.[mode], så .env.local, og til sidst den generelle .env-fil nederst. Den mest specifikke fil vinder altid over den mest generelle, hvilket giver dig mulighed for at have en fælles basisopsætning med lokale eller miljøspecifikke overskrivninger ved siden af.

Vil du have fuld typesikkerhed på dine egne miljøvariabler, udvider du grænsefladen ImportMetaEnv i vite-env.d.ts med dine egne felter. Skriver du herefter import.meta.env.VITE_API_URL et sted i koden, hvor variablen ikke findes i den udvidede grænseflade, markerer TypeScript det som en fejl med det samme, i stedet for at du først opdager en tom streng under kørsel i produktion.

Trin 10: Test-opsætning med Vitest

Vitest er test-runneren, der er bygget specifikt til at genbruge Vites konfiguration, transformationer og plugins, så du ikke skal vedligeholde to separate opsætninger til udvikling og test. Ifølge den samme npm-analyse fra maj 2026 havde vitest-pakken 45,1 mio. ugentlige downloads, en vækst på 311% år-over-år, hvilket viser, hvor udbredt kombinationen er blevet.

npm install -D vitest

Opret en simpel testfil, for eksempel sum.test.ts:

import { describe, it, expect } from 'vitest'
import { sum } from './sum'

describe('sum', () => {
  it('lægger to tal sammen', () => {
    expect(sum(2, 3)).toBe(5)
  })
})

Tilføj et script i package.json: "test": "vitest", og kør npm run test. Vitest kører i watch-mode som standard, ligesom Vites dev-server, og genkører kun de tests, der er relateret til den fil, du netop har gemt.

Vil du måle test-dækning, installerer du @vitest/coverage-v8 og kører vitest run --coverage. Rapporten viser, hvor mange procent af linjer, grene og funktioner dine tests rammer, opdelt per fil, og kan eksporteres som HTML til lokal gennemgang eller som lcov til CI-integration. Foretrækker du en visuel test-oplevelse frem for terminaloutput, tilbyder Vitest også et browserbaseret UI, som du starter med flaget --ui, hvor du kan se testresultater, fejlmeddelelser og dækningsgrafer i et interaktivt vindue.

Trin 11-12: Byg til produktion, Rolldown-motoren og deploy

Når appen er klar, bygger du den til produktion med:

npm run build

vite v8.0.2 building for production...
✓ 34 modules transformed.
dist/index.html                  0.46 kB │ gzip:  0.30 kB
dist/assets/index-C2n9k1Qa.css    1.28 kB │ gzip:  0.65 kB
dist/assets/index-B7xR4pLk.js   142.35 kB │ gzip: 45.71 kB
✓ built in 1.42s

Hvad Rolldown ændrer ved bygningen

Før Vite 8 brugte npm run build Rollup til at samle produktionsbundlen, mens dev-serveren brugte esbuild til hurtig transformation. Fra Vite 8 er Rolldown en indbygget mulighed for begge dele, skrevet i Rust i stedet for JavaScript. VoidZeros migrationsplan fra maj 2025 beskrev tre faser: først en separat pakke (rolldown-vite) til tidlige brugere, dernæst en sammenlægning med hovedprojektet med valgfri fuld-bundle-tilstand, og til sidst at gøre den tilstand til standard. Med version 8.0 fra marts 2026 er de to første faser gennemført, og fuld-bundle-tilstanden er tilgængelig direkte i standardinstallationen.

Du behøver ikke ændre noget i din kode for at drage fordel af det. Opgraderer du til Vite 8, arver du automatisk den nye motor, medmindre du eksplicit vælger den klassiske tilstand i konfigurationen.

Til deploy er en dist/-mappe med statiske filer alt, du behøver. De fleste moderne hosting-platforme genkender Vite-projekter automatisk og sætter build-kommandoen til npm run build og output-mappen til dist. Bruger du en platform, der kræver manuel konfiguration, ser en typisk opsætningsfil sådan ud:

# netlify.toml
[build]
  command = "npm run build"
  publish = "dist"

Vite vs Webpack: downloads, ydelse og tal i 2026

Pakke	Ugentlige downloads (2025)	Ugentlige downloads (2026)	Vækst år-over-år
vite	27,7 mio.	125,4 mio.	+353%
rolldown	50.000	28,8 mio.	+57.956%
vitest	ikke opgivet	45,1 mio.	+311%

Arkitektonisk er forskellen mellem de to værktøjer stadig markant, uafhængigt af downloadtal:

Egenskab	Vite 8	Webpack
Udviklingstilstand	Native ESM eller Rolldown fuld-bundle	Bundler hele appen før serveren starter
Bundler-motor	Rolldown (Rust) eller Rollup	webpack (JavaScript)
Konfiguration	vite.config.ts, ofte under 30 linjer	webpack.config.js, ofte flere hundrede linjer
Plugin-kompatibilitet	Rollup-plugin-API	Eget plugin- og loader-system
Indbygget test-runner	Vitest, delt konfiguration med Vite	Kræver separat opsætning, fx Jest

Faldgruber og fejlfinding du bør kende

At bruge process.env i stedet for import.meta.env. Vite er ikke Node.js, og process findes ikke i browseren som standard. Brug altid import.meta.env til miljøvariabler i klient-kode.
At glemme VITE_-præfikset. En variabel som API_KEY i din .env-fil bliver aldrig eksponeret til klienten, uanset hvor mange gange du genstarter serveren. Den skal hedde VITE_API_KEY.
At placere store filer forkert. Filer i public/ bliver kopieret som de er, uden hash eller optimering. Statiske assets, der skal cache-busted, hører til i src/assets/ og skal importeres.
At antage, at aliaser i vite.config.ts også virker i tsconfig.json automatisk. De to filer deler ikke konfiguration. Et alias skal defineres begge steder.
At blande CommonJS og ESM uden at forstå konsekvensen. Nogle ældre npm-pakker er skrevet i ren CommonJS og kan kræve optimizeDeps-justeringer eller et interop-plugin for at fungere med Vites ESM-først-tilgang.

Problem	Sandsynlig årsag	Løsning
“process is not defined” i browserkonsollen	Kode bruger process.env i klient-side kode	Erstat med import.meta.env og VITE_-præfiks
Miljøvariabel er undefined i appen	Manglende VITE_-præfiks eller forkert .env-fil indlæst	Tjek præfiks og kør vite –mode for at bekræfte det aktive miljø
TypeScript klager over “@/”-imports	paths mangler i tsconfig.json	Tilføj samme alias i compilerOptions.paths
HMR virker ikke, hele siden genindlæses	Komponenten eksporterer ikke korrekt, eller filen blander flere eksporttyper	Sørg for én default export pr. komponentfil
“Failed to resolve import” for en npm-pakke	Pakken er ren CommonJS og indekseres forkert	Tilføj pakken til optimizeDeps.include i vite.config.ts
Build fejler, men dev-server virker fint	Statisk analyse i build finder kode-stier, dev-tilstand ikke rammer	Kør npm run build lokalt tidligt og ofte, ikke kun i CI
CSS mangler i produktion, men virker i dev	Dynamisk importerede stylesheets bliver ikke fanget af build-analysen	Importer CSS statisk øverst i komponentfilen
Port 5173 er allerede optaget	En anden Vite-instans kører i baggrunden	Sæt server.port i konfigurationen eller luk den anden proces
Plugin-rækkefølge giver uventet output	Et plugin kører før et andet, det er afhængigt af	Omarranger plugins-arrayet efter dokumentationens anbefaling

Avancerede tips og det komplette projekt

Når det grundlæggende sidder fast, er der en række justeringer, der løfter et Vite-projekt fra “det virker” til produktionsklart.

Manuel chunk-splitting: brug build.rollupOptions.output.manualChunks til at adskille store afhængigheder som React eller chart-biblioteker i egne filer, så browseren kan cache dem separat fra din egen appkode, for eksempel manualChunks: { react: ['react', 'react-dom'] }. Det betyder, at en bruger, der besøger appen igen efter en ny udgivelse, kun skal downloade den ændrede appkode, ikke hele React-biblioteket på ny.
Forudindlæsning af moduler: Vite genererer automatisk modulepreload-tags for kritiske moduler, men du kan finjustere det med build.modulePreload-indstillinger, hvis du har komplekse routing-opsætninger.
Worker-support: importer en fil med ?worker-suffikset for automatisk at få den bundlet som en Web Worker, uden manuel opsætning af separate build-steps.
Monorepo-kompatibilitet: i et monorepo med flere pakker skal du sætte resolve.preserveSymlinks korrekt, så Vite finder lokale workspace-pakker uden at duplikere afhængigheder.
CI-cache: cache node_modules/.vite mellem CI-kørsler for at genbruge den forudoptimerede afhængighedscache og spare byggetid.

Vite 8: 353% Flere Downloads, Opsætning i 12 Trin [2026]

Vite vs Webpack: downloads, ydelse og tal i 2026

Faldgruber og fejlfinding du bør kende

Avancerede tips og det komplette projekt

Ofte stillede spørgsmål

Hvad er Vite, og hvorfor er det relevant i 2026

Forudsætninger: værktøjer og versioner du skal bruge

Trin 1-2: Installer Node.js og opret dit Vite-projekt

Trin 3-4: Projektstruktur, dev-server og Hot Module Replacement

Trin 5: Konfigurer vite.config.ts

Trin 6: TypeScript, path aliases og strict mode

Strict mode fra dag ét

Path aliases i tsconfig.json

Trin 7: CSS, Sass og statiske filer

Trin 8: Plugins til React, Vue og Svelte

Trin 9: Miljøvariabler med .env-filer

Trin 10: Test-opsætning med Vitest

Trin 11-12: Byg til produktion, Rolldown-motoren og deploy

Hvad Rolldown ændrer ved bygningen

Vite vs Webpack: downloads, ydelse og tal i 2026

Faldgruber og fejlfinding du bør kende

Avancerede tips og det komplette projekt

Ofte stillede spørgsmål

Seneste nyt