Sådan løser du Uncaught ReferenceError: process is not defined i Vite

Den vigtigste løsning er enkel: Hvis fejlen stammer fra din browserbaserede Vite-kode, skal du erstatte process.env med Vites import.meta.env-API. process-objektet tilhører Node.js, mens en normal Vite-klientapplikation kører i browseren. Vite eksponerer bevidst klientsikre miljøvariabler via import.meta.env i stedet.

For eksempel kan kode, der er migreret fra en anden værktøjskæde, indeholde process.env.REACT_APP_API_URL. I Vite er en typisk erstatning import.meta.env.VITE_API_URL, hvor VITE_API_URL er defineret i en .env-fil. Hvis fejlen stammer fra en tredjepartspakke snarere end din egen kildekode, kan den bedste løsning være at opdatere, erstatte eller konfigurere den pågældende pakke i stedet for at tilføje en generel Node.js-polyfill.

Denne vejledning følger den aktuelle Vite-dokumentation, der var tilgængelig den 11. september 2026. De autoritative referencer er Vites dokumentation om miljøvariabler og tilstande, dokumentation om fælles indstillinger og SSR-guide. For forskellen mellem browserkode og Node.js-runtime-API'er, se den officielle Node.js process-dokumentation.

Hvorfor siger Vite “process is not defined”?

Browseren har ingen indbygget Node.js process-global. Nodes dokumentation beskriver process som et objekt, der giver information om og kontrol over den nuværende Node.js-proces. Hvis kode, der forventer dette Node-objekt, når en browserbundle, kan en reference som process.env.API_URL fejle ved kørsel med ReferenceError: process is not defined.

Vites klientmodel er anderledes. Dets officielle miljø-API eksponerer værdier under import.meta.env. Vite leverer også indbyggede værdier såsom import.meta.env.MODE, import.meta.env.DEV, import.meta.env.PROD, import.meta.env.BASE_URL og import.meta.env.SSR.

Hvilken løsning gælder for dit projekt?

1. Erstat process.env i browserkode

Start med at søge i din kildekode-mappe efter process.env og bare referencer til process. Hvis referencen er i kode, der leveres til browseren, skal du konvertere den til Vites miljø-API.

Før:

const apiUrl = process.env.REACT_APP_API_URL

if (process.env.NODE_ENV === 'development') {
  console.log('Development mode')
}

Efter:

const apiUrl = import.meta.env.VITE_API_URL

if (import.meta.env.DEV) {
  console.log('Development mode')
}

Hvis du har brug for det nøjagtige tilstandsnavn snarere end en udviklings-/produktions-boolean, skal du bruge import.meta.env.MODE. Vite dokumenterer tilstande og NODE_ENV som relaterede men separate begreber, så antag ikke, at en brugerdefineret tilstand som staging er ækvivalent med at ændre NODE_ENV.

2. Omdøb klientmiljøvariabler med VITE_-præfikset

Som standard eksponerer Vite kun miljøvariabler, hvis navne starter med VITE_, til klientkildekode. Dette er en sikkerhedsgrænse, der er beregnet til at reducere utilsigtet eksponering af server-side hemmeligheder.

En projekt-niveau .env-fil kan indeholde:

VITE_API_URL=https://api.example.com
VITE_APP_NAME=Example App
DB_PASSWORD=do-not-expose-this

Klientkode kan læse import.meta.env.VITE_API_URL og import.meta.env.VITE_APP_NAME. Den upræfiksede DB_PASSWORD eksponeres ikke via import.meta.env som standard.

Behandl ikke VITE_-præfikset som hemmelig lagerplads. Vite advarer eksplicit om, at præfiksede værdier bundtes ind i klient-side-kode. Alt, der leveres til en browser, skal betragtes som læsbart for brugeren. API-hemmeligheder, private signeringsnøgler, databaseadgangskoder og lignende legitimationsoplysninger hører hjemme på en server, ikke i en Vite-klientbundle.

Vite indlæser .env og .env.local, samt tilstandsspecifikke filer som .env.production eller .env.staging. Tilstandsspecifikke værdier har forrang frem for generiske filer, mens variabler, der allerede er til stede i miljøet, når Vite starter, har højere prioritet end værdier fra filerne.

3. Genstart Vite efter ændring af .env-filer

Vite indlæser miljøfiler, når det starter. Efter du tilføjer, omdøber eller redigerer en værdi i en .env*-fil, skal du stoppe udviklingsserveren og starte den igen. En browseropdatering alene kan efterlade dig med at teste værdier, der blev indlæst før ændringen.

# stop the current dev server, then start it again
npm run dev

Bekræft også, at miljøfilen er i den mappe, Vite er konfigureret til at bruge. Den standard envDir er projektroden. Hvis dit projekt har en brugerdefineret root eller envDir, kan en korrekt navngivet variabel i den forkerte mappe stadig fremstå som undefined.

4. Verificer resultatet, før du ændrer noget andet

Genindlæs applikationen og tjek browserkonsollen. Den oprindelige process is not defined-undtagelse bør være væk. Verificer derefter den specifikke adfærd, der afhænger af variablen – for eksempel bør en API-anmodning målrette mod den forventede base-URL.

For midlertidig diagnose er det rimeligt at logge en ikke-hemmelig værdi som API-base-URL'en eller tilstanden. Fjern unødvendig logging bagefter, især hvis det kunne eksponere interne konfigurationsdetaljer.

Hvad hvis fejlen stammer fra en afhængighed?

Hvis din søgning ikke finder nogen process-reference i din kildekode, skal du inspicere stack-tracet. En sti inde i node_modules betyder ofte, at en pakke er skrevet med Node.js-antagelser, eller at den forkerte pakkeindgang er valgt til browserbrug.

Den sikreste rækkefølge er at opdatere afhængigheden, tjekke dens officielle dokumentation for browserunderstøttelse og foretrække en browserkompatibel pakke eller eksport. En generisk polyfill kan få en fejl til at forsvinde, mens andre Node-only-API'er forbliver uløste, så det er ikke automatisk en komplet løsning.

Hvis en afhængighed kun har brug for én compile-time-konstant, kan Vites define-indstilling udføre en målrettet global erstatning. For eksempel kan et snævert afgrænset kompatibilitetskrav håndteres ved at definere den nøjagtige identifikator, som afhængigheden læser, snarere end at fabrikere et fuldt process-objekt:

import { defineConfig } from 'vite'

export default defineConfig({
  define: {
    'process.env.LEGACY_FLAG': JSON.stringify('enabled')
  }
})

Brug dette kun, når du forstår, hvad afhængigheden forventer. Vite dokumenterer define som en global konstant-erstatning, der er tilgængelig under udvikling og statisk erstattes under build. Brug det ikke til at skubbe hemmeligheder ind i browserkode.

Hvornår er process.env gyldigt i et Vite-projekt?

Det kan være gyldigt i Node-side-kode. Et almindeligt eksempel er vite.config.ts. Vites nuværende konfigurationsdokumentation gør dog en vigtig distinktion: .env*-filer injiceres ikke automatisk i process.env, mens konfigurationsfilen oprindeligt evalueres. Hvis du har brug for disse filer inde i konfigurationen, skal du bruge Vites loadEnv-hjælper.

import { defineConfig, loadEnv } from 'vite'

export default defineConfig(({ mode }) => {
  const env = loadEnv(mode, process.cwd(), '')

  return {
    define: {
      __APP_API_URL__: JSON.stringify(env.APP_API_URL)
    }
  }
})

Det tomme præfiks, der sendes til loadEnv, betyder, at konfigurationen kan læse alle matchede værdier. Det eksponerer dem ikke automatisk for browseren, men enhver værdi, du bevidst placerer i define, kan blive en del af klientkode. Eksponer kun det, der er sikkert.

Hvad ændrer sig for SSR?

Vite skelner mellem klient- og servermiljøer. I et typisk SSR-setup kan serverkode køre i Node.js, mens klientbunden kører i browseren. Det betyder, at en process.env-reference kan være helt gyldig i et server-only-modul og ugyldig i et delt modul, der også udføres på klienten.

Hvis fejlen opstår kun efter hydrering eller browsernavigation, skal du tjekke, om et serverorienteret værktøj blev importeret ind i klientkode. Brug import.meta.env.SSR, hvor det er passende, til at skelne mellem udførelseskontekster, men hold også hemmeligheder og Node-only-API'er ude af klient-tilgængelige grene og moduler.

Almindelige løsninger, der skaber nye problemer

• Tilføjelse af window.process = {}: dette undertrykker kun nogle opslag og kan skjule det reelle kompatibilitetsproblem.
• Indstilling af envPrefix til en tom streng: Vite afviser dette eksplicit, fordi det kunne eksponere alle miljøvariabler for klientkode.
• Omdøbning af en hemmelighed til at starte med VITE_: det gør hemmeligheden egnet til klienteksponering; flyt hemmelighedsafhængigt arbejde til en backend i stedet.
• Ændring af kun .env-filen: du skal også opdatere kodehenvisninger fra process.env.NAME til import.meta.env.VITE_NAME og genstarte Vite.
• Polyfilling af alle Node-globaler: dette kan tilføje bundle-vægt og stadig fejle, hvis en afhængighed er afhængig af ikke-understøttede Node-moduler eller runtime-adfærd.

Et hurtigt migreringseksempel

Antag at et React-projekt tidligere havde denne fil:

REACT_APP_API_URL=https://api.example.com

og denne komponent:

const endpoint = process.env.REACT_APP_API_URL
fetch(`${endpoint}/users`)

I Vite, omdøb variablen:

VITE_API_URL=https://api.example.com

Skift derefter komponenten:

const endpoint = import.meta.env.VITE_API_URL
fetch(`${endpoint}/users`)

Genstart udviklingsserveren og test igen. Dette er den rigtige løsning, når værdien er sikker at eksponere for klienten. Hvis den gamle variabel indeholder en privat legitimationsoplysning, skal du ikke migrere den på denne måde; flyt den privilegerede operation bag en server-endpoint.

Endelig tjek: Hvordan ved du, at løsningen er komplet?

En komplet løsning har mere end ét tegn. Browseren rapporterer ikke længere process is not defined; dine forventede klientsikre variabler løser til de tilsigtede værdier; udviklings- og produktionsmiljøer opfører sig som forventet; og et produktionsbuild fungerer uden at introducere nye Node-global-fejl.

Kør din normale udviklingstest, opret derefter et produktionsbuild med dit projekts build-script og forhåndsvis eller udrul det i et miljø, der ligner produktion. Hvis fejlen kun opstår i produktion, skal du inspicere tilstandsspecifikke .env-filer og afhængighedskodeveje. Hvis den kun opstår i én afhængighed, skal du fokusere på den afhængighed i stedet for at tilføje stadig bredere shims til hele appen.

For de fleste Vite-applikationer er den holdbare regel ligetil: brug import.meta.env til klientkonfiguration, hold hemmeligheder på serveren, og reserver Node-globaler som process til kode, der faktisk kører i et Node-miljø.