Sådan løser du Module Not Found: Kan ikke løse fs i Webpack

Sidst verificeret: 11. september 2026. Fejlen “Module not found: Error: Can’t resolve 'fs'” betyder normalt, at Webpack bygger kode til en browser, men din kildekode – eller en af dens afhængigheder – importerer Node.js’ filsystemmodul. Node dokumenterer node:fs som API’en til interaktion med filsystemet, mens Webpacks aktuelle dokumentation angiver, at Webpack 5 ikke længere automatisk polyfiller Node.js’ kerne-moduler til browser-builds.

Det vigtige er at vælge den løsning, der matcher, hvad koden faktisk forsøger at gøre. Der findes ingen enkelt indstilling, der er korrekt for alle projekter. Hvis din applikation virkelig har brug for at læse filer fra serverens disk, skal du flytte dette arbejde til Node/server-kode. Hvis en afhængighed importerer fs kun for en valgfri Node-kun-funktion, som din browser-bundle aldrig bruger, kan resolve.fallback: { fs: false } være passende. Hvis pakken har et browserkompatibelt build, skal du bruge det i stedet. Og hvis bundlen er beregnet til at køre i Node, skal du målrette mod Node i stedet for at foregive, at det er en web-bundle.

Hurtig beslutningstabel

Webpacks officielle resolve.fallback-dokumentation angiver, at Webpack 5 ikke længere automatisk polyfiller Node-kerne-moduler. Dens Webpack 5 udgivelsesnoter forklarer årsagen: automatiske polyfills kunne tilføje store, unødvendige kompatibilitetskoder til frontend-bundles, så Webpack flyttede ansvaret til applikationen eller pakkeforfatteren.

Trin 1: Find ud af, hvem der importerer fs

Start med den første nyttige linje i Webpacks fejloutput. Den peger normalt på den fil, hvor opløsningen fejlede, for eksempel:

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

Hvis den fejlede fil er din, skal du søge i den efter enten form:

const fs = require('fs')

// eller
import fs from 'node:fs'

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

Nodes officielle File System-dokumentation bekræfter, at node:fs og node:fs/promises er Node-API’er til filsystemoperationer. En normal browser-bundle får ikke adgang til serverens disk, blot fordi Webpack kan analysere importen.

Hvis den fejlede fil er under node_modules, skal du ikke straks redigere den pakke på stedet. Identificer først, hvilken top-niveau-afhængighed, der bragte den ind i din browser-bundle. Det nyttige spørgsmål er ikke kun “Hvilken pakke importerer fs?” men “Hvorfor er den Node-orienterede kodevej tilgængelig fra mit klient-entry-point?”

Brug denne diagnose når: fejlen opstår efter opgradering af Webpack, tilføjelse af en afhængighed, import af et tidligere server-kun-værktøj i frontend-kode, eller flytning af delt kode til en klient-bundle.

Praktisk tjek: fjern midlertidigt importen, der fører til den fejlede modul, og genbyg. Hvis fs-fejlen forsvinder, har du bekræftet afhængighedsstien, før du ændrer Webpack-konfigurationen.

Trin 2: Hvis koden virkelig har brug for filsystemadgang, flyt den til Node/server-kode

Dette er den bedste løsning, når koden har brug for at læse konfigurationsfiler, skabeloner, lokale dokumenter, private nøgler, genererede aktiver, serverlogs eller noget andet 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 det bør ikke trækkes ind i et browser-entry-point. Eksponér i stedet resultatet gennem din applikations serverlag. En forenklet opdeling kunne 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)
})

// browser-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()
}

Afvejningen er arkitektonisk: du tilføjer et server-endpoint eller en anden serverside grænse, men du bevarer semantikken i fs. Browseren anmoder om data; serveren læser filsystemet.

Denne løsning er passende når: filsystemoperationen er reel og nødvendig.

Denne løsning er ikke nødvendig når: importen kun eksisterer inde i en valgfri Node-kodevej, som browseren aldrig udfører. I det tilfælde kan et browserspecifikt pakke-entry-point eller en ignoreret fallback være renere.

Trin 3: Brug kun resolve.fallback: { fs: false }, når filsystemadfærd er valgfri

Webpacks officielle Webpack 4-til-5 migreringsvejledning siger specifikt, at konfigurationer, der bruger det gamle mønster node.fs: 'empty', skal flytte til:

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

Se den officielle Webpack 5 migreringsvejledning.

At sætte en fallback til false fortæller Webpack ikke at inkludere en implementering for det uløste modul. Dette kan være præcis rigtigt for en pakke, der indeholder en beskyttet Node-kun-gren, såsom kode, der bruger fs kun under server-rendering eller CLI-eksekvering.

Det kan også skjule build-fejlen, mens det efterlader dig med en runtime-design-fejl. Overvej denne afhængighed:

const fs = require('fs')

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

Hvis din browser faktisk kalder loadUserConfig(), skaber erstatning af fs med “ingenting” ikke et fungerende browser-filsystem. Bygget kan fortsætte, men funktionen kan stadig ikke udføre den tilsigtede Node-operation.

Brug fs: false når: du har verificeret, at den filsystemspecifikke gren ikke bruges i web-målet.

Brug det ikke når: din browserfunktion afhænger af readFileSync, mappegennemgang, serverstier eller anden reel Node-filsystemadfærd.

Hvorfor “bare installer en fs-polyfill” normalt er det forkerte første svar

Webpacks aktuelle resolve.fallback-dokumentation giver eksempler på manuelle polyfills for flere Node-kerne-moduler såsom path, buffer, stream og crypto. Bemærkelsesværdigt giver dens kompatibilitetsliste ikke en generel fs-erstatning svarende til Node-filsystemet.

Denne forskel er vigtig. JavaScript-værktøjer kan ofte reproduceres i en browser. Vilklårlig adgang til værts-/serverfilsystemet er en runtime-funktion, ikke blot en manglende hjælpefunktion.

Hvis det, du virkelig har brug for, er en browser-workflow, skal du vælge et browser-nativt design for den specifikke opgave – for eksempel hent et aktiv fra en URL, lad brugeren vælge en fil, eller gem applikationsdata ved hjælp af en passende browser-lagringsmekanisme. Døm ikke succes kun ud fra, om Webpack holder op med at vise fejlen.

Mulighed 4: Foretræk en browserkompatibel afhængighed eller pakkeeksport

Hvis fejlen kommer fra en tredjepartspakke, skal du undersøge, om den pakke officielt understøtter browsere. Webpacks aktuelle pakke exports-vejledning forklarer, at pakker kan levere betingede eksporter for miljøer såsom browser og node. Webpacks udgivelsesvejledning anbefaler også, at pakkeforfattere leverer frontend-kompatible alternativer, når Node-kun-implementeringer er uegnede til browsere.

For eksempel kan en pakke konceptuelt eksponere:

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

Hvis en opgraderet pakkeversion leverer et ordentligt browser-entry-point, mens din ældre version ikke gør det, kan opgradering være sikrere end at konfigurere fs: false. Ligeledes kan udskiftning af en Node-orienteret pakke med en, der er eksplicit designet til browserbrug, reducere kompatibilitetshacks og bundle-kompleksitet.

Vælg denne rute når: afhængigheden er beregnet til at fungere i browsere, men den installerede version vælger eller eksponerer en Node-kun-implementering.

Afvejning: opgradering eller udskiftning af en pakke kan introducere API-ændringer, så kør dine normale applikationstests i stedet for at behandle en vellykket kompilering som tilstrækkelig.

Mulighed 5: Hvis outputtet er en Node-bundle, skal du sætte målet til Node

Nogle gange producerer Webpack slet ikke browserkode. Du bundler måske en CLI, baggrundsarbejder, build-værktøj, SSR-server eller Node-tjeneste. I det tilfælde er det bagvendt at forsøge at undertrykke fs: runtime’en leverer det faktisk.

Webpacks officielle Targets-dokumentation siger, at:

module.exports = {
  target: 'node'
}

kompilerer for et Node.js-lignende miljø og efterlader indbyggede moduler såsom fs og path til, at Node leverer dem ved runtime.

Webpacks mere detaljerede target-konfigurationsreference skelner også mellem web, node, Electron-mål, web-arbejdere og andre miljøer.

Brug target: 'node' når: det resulterende JavaScript vil eksekvere under Node.

Brug det ikke til at “fikse” en normal browser-SPA: ændring af målet får ikke en browser til pludselig at levere Nodes filsystem-API’er. Det ændrer, hvilket miljø Webpack antager vil eksekvere bundlen.

Avancerede Node-builds: externals kan holde indbyggede moduler ved runtime

For server-bundles leverer Webpack også Node-orienteret externals-adfærd. Dens officielle Externals-dokumentation angiver, at externalsPresets.node kan behandle Node-indbyggede moduler såsom fs, path og vm som eksterne og indlæse dem med Nodes runtime require().

En typisk Node-orienteret konfiguration kunne derfor se sådan ud:

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

Dette er et avanceret server-bundle-anliggende, ikke en browser-workaround.

Trin 4: Genbyg, og test derefter funktionen, der forårsagede importen

Efter at have foretaget den arkitektoniske eller konfigurationsmæssige ændring, skal du genbygge:

npm run build

En ren kompilering beviser kun, at modulopløsningen lykkedes. Det beviser ikke, at den berørte funktion opfører sig korrekt. Test i henhold til den løsning, du valgte:

• Hvis du flyttede filadgang til serveren, skal du kalde browserfunktionen og verificere, at server-endpointet returnerer de forventede data.
• Hvis du satte fs: false, skal du udøve afhængigheden i browseren og bekræfte, at den aldrig indtræder i den filsystemafhængige gren.
• Hvis du skiftede til et browser-build af en pakke, skal du køre pakkens rigtige brugerrettede workflow.
• Hvis du ændrede målet til Node, skal du eksekvere det byggede output under den Node-version, du understøtter.

Sammenligning af almindelige løsninger

Særligt tilfælde: delt kode importeret af både browser- og server-bundles

En hyppig kilde til denne fejl er et værktøjsmodul, der indeholder både rene funktioner og Node-kun-hjælpere:

// 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')
}

Selvom din browser kun importerer formatDate, kan den top-niveau fs-import tvinge Webpack til at løse fs. Et renere design er at opdele modulerne:

// 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 gør runtime-grænsen synlig i modulgrafet i stedet for at afhænge af tree-shaking eller en fallback for at fjerne en inkompatibel import.

Særligt tilfælde: fejlen opstod efter opgradering fra Webpack 4

Dette er et af de klassiske Webpack 5 migreringssymptomer. Webpack 4 leverede automatisk kompatibilitets-shims for mange Node-kerne-moduler. Webpack 5 stoppede med vilje med at gøre det. Hvis din kode “virke før opgraderingen”, skal du spørge, om den virkelig havde brug for Node-funktionen i browseren, eller om den gamle bundler stille og roligt injicerede kompatibilitetskode.

Den officielle Webpack migreringsvejledning anbefaler at læse build-fejlens vejledning om breaking changes og erstatte gammel node.*-kompatibilitetskonfiguration med den nyere resolver-tilgang, hvor det er passende.

Antag ikke, at genskabelse af hver eneste Webpack 4-polyfill er den bedste migrering. Webpacks egne udgivelsesnoter anbefaler frontend-kompatible moduler, hvor det er muligt.

Endelig selvkontrol

Før du lukker sagen, skal du verificere disse punkter:

1. Find den præcise kildefil eller afhængighed, der importerer fs.
2. Bekræft, om den berørte bundle kører i en browser eller i Node.
3. Hvis det er en browser-bundle, skal du verificere, om funktionen faktisk har brug for filsystemadfærd.
4. Hvis den har det, skal du flytte filsystemoperationen bag en servergrænse.
5. Hvis afhængighedens fs-brug er valgfri og aldrig eksekveres i browseren, skal du overveje resolve.fallback: { fs: false }.
6. Hvis pakken officielt leverer en browser-eksport, skal du foretrække det frem for at undertrykke nødvendig adfærd.
7. Hvis bundlen eksekverer i Node, skal du bruge et Node-mål i stedet for et web-mål.
8. Genbyg og bekræft, at modulopløsningsfejlen er væk.
9. Kør den faktiske funktion, der tidligere trak fs ind; stop ikke ved “kompileret vellykket”.

Den holdbare løsning er at tilpasse koden til dens runtime. fs hører til Nodes filsystemmiljø. Webpack 5 gør denne grænse mere synlig ved ikke længere automatisk at injicere Node-kerne-polyfills. Når du først har besluttet, om filsystemarbejdet hører til på serveren, er valgfrit i browseren, eller er en del af en Node-målrettet bundle, bliver den korrekte konfiguration meget lettere at vælge.