Slik løser du feilen «Module not found: Can’t resolve 'fs'» i Webpack

Sist verifisert: 11. september 2026. Feilen «Module not found: Error: Can’t resolve 'fs'» betyr vanligvis at Webpack bygger kode for en nettleser, men at kildekoden din – eller en av dens avhengigheter – importerer Node.js’ filsystemmodul. Node dokumenterer node:fs som API-et for å samhandle med filsystemet, mens Webpacks gjeldende dokumentasjon sier at Webpack 5 ikke lenger automatisk polyfiller Node.js’ kjerne-moduler for nettleserbygger.

Det viktige er å velge løsningen som samsvarer med hva koden faktisk prøver å gjøre. Det finnes ingen enkeltinnstilling som er riktig for alle prosjekter. Hvis applikasjonen din virkelig trenger å lese filer fra serverens disk, flytt dette arbeidet til Node/serverkode. Hvis en avhengighet importerer fs kun for en valgfri Node-kun-funksjon som nettleserpakken din aldri bruker, kan resolve.fallback: { fs: false } være passende. Hvis pakken har en nettleserkompatibel bygging, bruk den i stedet. Og hvis pakken er ment å kjøre i Node, mål mot Node i stedet for å late som om det er en nettleserpakke.

Rask beslutningstabell

Webpacks offisielle dokumentasjon for resolve.fallback angir at Webpack 5 ikke lenger polyfiller Node-kjerne-moduler automatisk. Dens utgivelsesnotater for Webpack 5 forklarer årsaken: automatiske polyfills kunne legge til store, unødvendige kompatibilitetskoder i frontend-pakker, så Webpack flyttet ansvaret til applikasjonen eller pakkeforfatteren.

Steg 1: Finn ut hvem som importerer fs

Start med den første nyttige linjen i Webpacks feilutdata. Den peker vanligvis til filen hvor oppløsningen feilet, for eksempel:

ERROR in ./src/utils/fileHelper.js 1:0-20
Module not found: Error: Can't resolve 'fs'

Hvis den feilende filen er din, søk i den etter begge former:

const fs = require('fs')

// eller
import fs from 'node:fs'

// eller
import { readFile } from 'node:fs/promises'

Nodes offisielle dokumentasjon for filsystemet bekrefter at node:fs og node:fs/promises er Node-API-er for filsystemoperasjoner. En vanlig nettleserpakke får ikke tilgang til serverens disk bare fordi Webpack kan analysere importen.

Hvis den feilende filen er under node_modules, ikke rediger den pakken på stedet umiddelbart. Identifiser først hvilken toppnivåavhengighet som brakte den inn i nettleserpakken din. Det nyttige spørsmålet er ikke bare «Hvilken pakke importerer fs?», men «Hvorfor er den Node-orienterte kodebanen tilgjengelig fra klientinngangen min?»

Bruk denne diagnosen når: feilen oppstår etter oppgradering av Webpack, tillegging av en avhengighet, import av et tidligere server-kun-verktøy i frontend-kode, eller flytting av delt kode til en klientpakke.

Praktisk sjekk: fjern midlertidig importen som fører til den feilende modulen og bygg på nytt. Hvis fs-feilen forsvinner, har du bekreftet avhengighetsbanen før du endrer Webpack-konfigurasjonen.

Steg 2: Hvis koden virkelig trenger filsystemtilgang, flytt den til Node/serverkode

Dette er den beste løsningen når koden trenger å lese konfigurasjonsfiler, maler, lokale dokumenter, private nøkler, genererte eiendeler, serverlogger eller noe annet fra maskinens filsystem.

For eksempel er dette passende i Node:

import { readFile } from 'node:fs/promises'

export async function loadTemplate() {
  return readFile('./templates/email.html', 'utf8')
}

Men den bør ikke trekkes inn i en nettleserinngang. Eksponer i stedet resultatet gjennom applikasjonens serverlag. En forenklet oppdeling kan være:

// server-side kode
import { readFile } from 'node:fs/promises'

app.get('/api/template', async (req, res) => {
  const text = await readFile('./templates/email.html', 'utf8')
  res.type('text/plain').send(text)
})

// nettleser-side kode
export async function loadTemplate() {
  const response = await fetch('/api/template')
  if (!response.ok) throw new Error('Failed to load template')
  return response.text()
}

Kompromisset er arkitektonisk: du legger til et server-endepunkt eller en annen serverside grense, men du bevarer semantikken til fs. Nettleseren ber om data; serveren leser filsystemet.

Denne løsningen er passende når: filsystemoperasjonen er reell og nødvendig.

Denne løsningen er ikke nødvendig når: importen kun finnes inne i en valgfri Node-kodebane som nettleseren aldri utfører. I det tilfellet kan en nettleserspesifikk pakkeinngang eller en ignorert fallback være renere.

Steg 3: Bruk resolve.fallback: { fs: false } kun når filsystematferd er valgfritt

Webpacks offisielle migreringsguide fra Webpack 4 til 5 sier spesifikt at konfigurasjoner som bruker det gamle mønsteret node.fs: 'empty' bør gå over til:

module.exports = {
  // ...
  resolve: {
    fallback: {
      fs: false
    }
  }
}

Se den offisielle Webpack 5-migreringsguiden.

Å sette en fallback til false forteller Webpack å ikke inkludere en implementering for den uløste modulen. Dette kan være nøyaktig riktig for en pakke som inneholder en beskyttet Node-kun-gren, som kode som bruker fs kun under serverrendering eller CLI-utførelse.

Det kan også skjule byggefeilen mens du sitter igjen med en designfeil ved kjøretid. Vurder denne avhengigheten:

const fs = require('fs')

export function loadUserConfig(path) {
  return fs.readFileSync(path, 'utf8')
}

Hvis nettleseren din faktisk kaller loadUserConfig(), erstatter fs med «ingenting» ikke et fungerende nettleserfilsystem. Bygget kan fortsette, men funksjonen kan fortsatt ikke utføre den tiltenkte Node-operasjonen.

Bruk fs: false når: du har verifisert at den filsystemspesifikke grenen ikke brukes i nettlesermålet.

Ikke bruk den når: nettleserfunksjonen din avhenger av readFileSync, kataloggjennomgang, serverstier eller annen reell Node-filsystematferd.

Hvorfor «bare installer en fs-polyfill» vanligvis er feil første svar

Webpacks gjeldende dokumentasjon for resolve.fallback gir eksempler på manuelle polyfills for flere Node-kjerne-moduler som path, buffer, stream og crypto. Merk at kompatibilitetslisten ikke gir en generell fs-erstatning som er ekvivalent med Node-filsystemet.

Denne forskjellen er viktig. JavaScript-verktøy kan ofte reproduseres i en nettleser. Vilkårlig tilgang til verts-/serverfilsystemet er en kjøretidskapabilitet, ikke bare en manglende hjelpefunksjon.

Hvis det du virkelig trenger er en nettleserarbeidsflyt, velg et nettlesernativt design for den spesifikke oppgaven – for eksempel, hent en eiendel fra en URL, la brukeren velge en fil, eller lagre applikasjonsdata ved hjelp av en passende nettleserlagringsmekanisme. Døm ikke suksess kun etter om Webpack slutter å vise feilen.

Alternativ 4: Foretrekk en nettleserkompatibel avhengighet eller pakkeeksport

Hvis feilen kommer fra en tredjepartspakke, inspiser om den pakken offisielt støtter nettlesere. Webpacks gjeldende guide for pakke exports forklarer at pakker kan gi betingede eksporter for miljøer som browser og node. Webpacks utgivelsesveiledning anbefaler også at pakkeforfattere gir frontend-kompatible alternativer når Node-kun-implementeringer er uegnede for nettlesere.

For eksempel kan en pakke konseptuelt eksponere:

{
  "exports": {
    ".": {
      "browser": "./dist/browser.js",
      "node": "./dist/node.js",
      "default": "./dist/browser.js"
    }
  }
}

Hvis en oppgradert pakkeversjon gir en riktig nettleserinngang mens den eldre versjonen din ikke gjør det, kan oppgradering være tryggere enn å konfigurere fs: false. Tilsvarende kan erstatning av en Node-orientert pakke med en som er eksplisitt designet for nettleserbruk redusere kompatibilitetshacks og pakkekompleksitet.

Velg denne ruten når: avhengigheten er ment å fungere i nettlesere, men den installerte versjonen velger eller eksponerer en Node-kun-implementering.

Kompromiss: oppgradering eller erstatning av en pakke kan introdusere API-endringer, så kjør de vanlige applikasjonstestene dine i stedet for å behandle en vellykket kompilering som tilstrekkelig.

Alternativ 5: Hvis utdata er en Node-pakke, sett målet til Node

Ikke alltid produserer Webpack nettleserkode i det hele tatt. Du kan pakke en CLI, bakgrunnsarbeider, byggeverktøy, SSR-server eller Node-tjeneste. I det tilfellet er det bakvendt å prøve å undertrykke fs: kjøretidsmiljøet gir faktisk den.

Webpacks offisielle dokumentasjon for Targets sier at:

module.exports = {
  target: 'node'
}

kompilerer for et Node.js-lignende miljø og lar innebygde moduler som fs og path bli levert av Node ved kjøretid.

Webpacks mer detaljerte referanse for target-konfigurasjon skiller også mellom web, node, Electron-mål, nettleserarbeidere og andre miljøer.

Bruk target: 'node' når: den resulterende JavaScript-koden vil utføre under Node.

Ikke bruk den for å «fikse» en vanlig nettleser-SPA: endring av målet gjør ikke at en nettleser plutselig gir Nodes filsystem-API-er. Det endrer hvilket miljø Webpack antar vil utføre pakken.

Avanserte Node-bygg: externals kan holde innebygde moduler ved kjøretid

For serverpakker gir Webpack også Node-orientert externals-atferd. Dens offisielle dokumentasjon for Externals angir at externalsPresets.node kan behandle Node-innbygde moduler som fs, path og vm som eksterne og laste dem med Nodes kjøretids require().

En typisk Node-orientert konfigurasjon kan derfor se ut som:

module.exports = {
  target: 'node',
  externalsPresets: {
    node: true
  }
}

Dette er en avansert serverpakke-bekymring, ikke en nettleser-workaround.

Steg 4: Bygg på nytt, og test deretter funksjonen som forårsaket importen

Etter å ha gjort den arkitektoniske eller konfigurasjonsmessige endringen, bygg på nytt:

npm run build

En ren kompilering beviser bare at moduloppløsningen lyktes. Det beviser ikke at den berørte funksjonen oppfører seg korrekt. Test i henhold til løsningen du valgte:

• Hvis du flyttet filtilgang til serveren, kall nettleserfunksjonen og verifiser at server-endepunktet returnerer de forventede dataene.
• Hvis du satte fs: false, utøv avhengigheten i nettleseren og bekreft at den aldri går inn i den filsystemavhengige grenen.
• Hvis du byttet til en nettleserbygging av en pakke, kjør pakkens virkelige brukerrettede arbeidsflyt.
• Hvis du endret målet til Node, utfør den bygde utdataen under Node-versjonen du støtter.

Vanlige løsninger sammenlignet

Spesielt tilfelle: delt kode importert av både nettleser- og serverpakker

En hyppig kilde til denne feilen er et verktøymodul som inneholder både rene funksjoner og Node-kun-hjelpere:

// shared-utils.js
import fs from 'node:fs'

export function formatDate(date) {
  return new Intl.DateTimeFormat('en-US').format(date)
}

export function readConfig(path) {
  return fs.readFileSync(path, 'utf8')
}

Selv om nettleseren din kun importerer formatDate, kan den toppnivå fs-importen tvinge Webpack til å løse fs. Et renere design er å splitte modulene:

// shared/formatDate.js
export function formatDate(date) {
  return new Intl.DateTimeFormat('en-US').format(date)
}

// server/readConfig.js
import fs from 'node:fs'

export function readConfig(path) {
  return fs.readFileSync(path, 'utf8')
}

Dette gjør kjøretidsgrensen synlig i modulgrafet i stedet for å stole på tree-shaking eller en fallback for å fjerne en inkompatibel import.

Spesielt tilfelle: feilen dukket opp etter oppgradering fra Webpack 4

Dette er et av de klassiske Webpack 5-migreringssymptomene. Webpack 4 leverte automatisk kompatibilitetsshim for mange Node-kjerne-moduler. Webpack 5 sluttet med vilje å gjøre det. Hvis koden din «fungerte før oppgraderingen», spør om den virkelig trengte Node-funksjonen i nettleseren, eller om den gamle bundleren stille injiserte kompatibilitetskode.

Den offisielle Webpack-migreringsguiden anbefaler å lese veiledningen for ødeleggende endringer i byggefeilen og erstatte gammel node.*-kompatibilitetskonfigurasjon med den nyere resolver-tilnærmingen der det er passende.

Ikke anta at gjenskaping av hver eneste Webpack 4-polyfill er den beste migreringen. Webpacks egne utgivelsesnotater anbefaler frontend-kompatible moduler der det er mulig.

Endelig selvkontroll

Før du lukker saken, verifiser disse punktene:

1. Finn den nøyaktige kildefilen eller avhengigheten som importerer fs.
2. Bekreft om den berørte pakken kjører i en nettleser eller i Node.
3. Hvis det er en nettleserpakke, verifiser om funksjonen faktisk trenger filsystematferd.
4. Hvis den gjør det, flytt filsystemoperasjonen bak en servergrense.
5. Hvis avhengighetens fs-bruk er valgfri og aldri utført i nettleseren, vurder resolve.fallback: { fs: false }.
6. Hvis pakkene offisielt gir en nettleser-eksport, foretrekk den fremfor å undertrykke nødvendig atferd.
7. Hvis pakken utfører i Node, bruk et Node-mål i stedet for et nettlesermål.
8. Bygg på nytt og bekreft at moduloppløsingsfeilen er borte.
9. Kjør den faktiske funksjonen som tidligere trakk inn fs; ikke stopp ved «kompilert vellykket».

Den varige løsningen er å tilpasse koden til kjøretidsmiljøet. fs tilhører Nodes filsystemmiljø. Webpack 5 gjør denne grensen mer synlig ved å ikke lenger injisere Node-kjerne-polyfills automatisk. Når du først har bestemt om filsystemarbeidet hører hjemme på serveren, er valgfritt i nettleseren, eller er en del av en Node-rettet pakke, blir den riktige konfigurasjonen mye lettere å velge.