Hvernig á að laga Module Not Found: Get ekki leyst fs í Webpack

Síðast staðfest: 11. september 2026. Villan “Module not found: Error: Can’t resolve 'fs'” þýðir yfirleitt að Webpack sé að byggja kóða fyrir vafra, en upprunakóðinn þinn—einn af óháðum honum—flytur inn skráakerfiseiningu Node.js. Node skjalfestir node:fs sem API til að eiga samskipti við skráakerfið, en núverandi skjöl Webpack segja að Webpack 5 fylli ekki lengur sjálfkrafa á Node.js kjarnaeiningar fyrir vafrauppbyggingar.

Lykilatriðið er að velja lausnina sem passar við það sem kóðinn er í raun og veru að reyna að gera. Það er engin ein stilling sem er rétt fyrir öll verkefni. Ef forritið þitt þarf virkilega að lesa skrár af diski netþjónsins, færa þá vinnuna yfir í Node/netþjónakóða. Ef óháð flytur inn fs aðeins fyrir valkvæða Node-einkaréttar eiginleika sem vafrauppbyggingin þín notar aldrei, gæti resolve.fallback: { fs: false } verið viðeigandi. Ef pakkinn hefur vafra-samanhæft byggingu, notaðu þá það í staðinn. Og ef uppbyggingin er ætluð til að keyra í Node, miðaðu þá á Node í stað þess að láta sem hún sé vefuppbygging.

Hraðákvörðunartafla

Opinber resolve.fallback skjölun Webpack segir að Webpack 5 fylli ekki lengur sjálfkrafa á Node kjarnaeiningar. Útgáfunótur Webpack 5 útskýra ástæðuna: sjálfvirkir polyfills gætu bætt við stórum, óþarfa samhæfingar kóða í framenda uppbyggingar, svo Webpack flutti ábyrgðina yfir á forritið eða pakka höfundinn.

Skref 1: Finna út hver flytur inn fs

Byrjaðu á fyrstu gagnlegu línu í villuúttaki Webpack. Hún vísar yfirleitt til skráarinnar þar sem leysti mistókst, til dæmis:

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

Ef skráin sem mistekst er þín, leitaðu í henni að hvoru formi:

const fs = require('fs')

// eða
import fs from 'node:fs'

// eða
import { readFile } from 'node:fs/promises'

Opinber skjölun Node fyrir skráakerfið staðfestir að node:fs og node:fs/promises eru Node API fyrir skráakerfis aðgerðir. Venjuleg vafrauppbygging fær ekki aðgang að diski netþjónsins bara vegna þess að Webpack getur greint innflutninginn.

Ef skráin sem mistekst er undir node_modules, ekki breyta pakkanum beint strax. Fyrst skilgreindu hvaða efsta stigs óháð kom honum inn í vafrauppbygginguna þína. Gagnlegi spurningin er ekki bara “Hvaða pakki flytur inn fs?” heldur “Af hverju er sá Node-hugsaði kóðaleið sýnilegur frá viðtaks inngangspunktinum mínum?”

Notaðu þessa greiningu þegar: villan kemur fram eftir uppfærslu á Webpack, viðbót óháðar, innflutningur á áður netþjón-einkaréttar hjálparforriti í framenda kóða, eða flutningur sameiginlegs kóða í viðtaks uppbyggingu.

Hagnýtur athugun: fjarlægðu tímabundið innflutninginn sem leiðir til misteknu einingarinnar og endurbyggðu. Ef fs villan hverfur, hefur þú staðfest óháðarleiðina áður en þú breytir Webpack stillingum.

Skref 2: Ef kóðinn þarf virkilega skráakerfis aðgang, færa hann yfir í Node/netþjónakóða

Þetta er besta lagfæringin þegar kóðinn þarf að lesa stillingarskrár, sniðmát, staðbundin skjöl, einkalykla, búna eignir, netþjónaskrár, eða eitthvað annað frá skráakerfi vélarinnar.

Til dæmis, þetta er viðeigandi í Node:

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

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

En það ætti ekki að dragast inn í vafra inngangspunkt. Í staðinn, birtu niðurstöðuna í gegnum netþjónslagi forritsins þíns. Einfaldaður skipting gæti verið:

// netþjónakóði
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)
})

// vafra-kóði
export async function loadTemplate() {
  const response = await fetch('/api/template')
  if (!response.ok) throw new Error('Failed to load template')
  return response.text()
}

Gallið er arkitektúrskt: þú bætir við netþjón endapunkti eða öðru netþjónskilyrði, en þú varðveitir merkingu fs. Vafrið biður um gögn; netþjónninn les skráakerfið.

Þessi lausn er viðeigandi þegar: skráakerfis aðgerðin er raunveruleg og nauðsynleg.

Þessi lausn er ekki nauðsynleg þegar: innflutningurinn er aðeins til staðar inni í valkvæðum Node kóðaleið sem vafrið keyrir aldrei. Í því tilviki, getur vafra-einkaréttur pakka inngangspunktur eða hunsaður fallback verið hreinna.

Skref 3: Notaðu resolve.fallback: { fs: false } aðeins þegar skráakerfis hegðun er valkvæð

Opinber Webpack 4-til-5 flutningsleiðbeiningar Webpack segja sérstaklega að stillingar sem nota gamla mynstrið node.fs: 'empty' ættu að færa sig yfir í:

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

Sjáðu opinberu Webpack 5 flutningsleiðbeiningarnar.

Að stilla fallback á false segir Webpack að ekki taka með útfærslu fyrir þá óleystu einingu. Þetta getur verið nákvæmlega rétt fyrir pakka sem inniheldur varðveittan Node-einkaréttar grein, eins og kóða sem notar fs aðeins við netþjóns myndun eða CLI keyrslu.

Það getur einnig falið byggingarvilluna en skilið þig eftir með hönnunargalla í keyrslutíma. Íhugaðu þessa óháð:

const fs = require('fs')

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

Ef vafrið þitt kallar virkilega á loadUserConfig(), að skipta fs út fyrir “ekkert” skapar ekki virkan vafra skráakerfi. Byggingin gæti haldið áfram, en eiginleikinn getur samt ekki framkvæmt ætlaða Node aðgerð.

Notaðu fs: false þegar: þú hefur staðfest að skráakerfis-einkaréttar greinin er ekki notuð í vefmarkmiðinu.

Ekki notaðu það þegar: vafra eiginleikinn þinn er háður readFileSync, möppu ferðalög, netþjónsleiðir, eða aðrar raunverulegar Node skráakerfis hegðanir.

Af hverju “bara setja upp fs polyfill” er yfirleitt rangt fyrsta svar

Núverandi resolve.fallback skjölun Webpack gefur dæmi um handvirka polyfills fyrir nokkrar Node kjarnaeiningar eins og path, buffer, stream, og crypto. Athyglisvert er að samhæfingarlistinn veitir ekki almenna fs staðgengil jafngildan Node skráakerfinu.

Þessi munur er mikilvægur. JavaScript hjálparforrit geta oft verið endurtekin í vafra. Handahófskenndur aðgangur að hýsingar/netþjóns skráakerfinu er keyrslutíma geta, ekki bara vantar hjálparfall.

Ef það sem þú þarft virkilega er vafra vinnuflæði, veldu vafra-einkarétt hönnun fyrir tiltekna verkefni—til dæmis, sækja eign frá URL, leyfa notandanum að velja skrá, eða geyma forritagögn með viðeigandi vafra geymslu aðferð. Dæma ekki velgengni eingöngu eftir því hvort Webpack hættir að sýna villuna.

Valkostur 4: Kjósa vafra-samanhæft óháð eða pakka útflutning

Ef villan kemur frá þriðja aðila pakka, skoðaðu hvort sá pakki styðji vafra opinberlega. Núverandi pakka exports leiðbeiningar Webpack útskýra að pakkar geta veitt skilyrðisbundna útflutninga fyrir umhverfi eins og browser og node. Útgáfu leiðbeiningar Webpack mæla einnig með að pakka höfundar veiti framenda-samanhæfða valkosti þegar Node-einkaréttar útfærslur eru óhæfilegar fyrir vafra.

Til dæmis, pakki gæti huglægt birt:

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

Ef uppfærð pakka útgáfa veitir réttan vafra inngangspunkt en eldri útgáfan þín gerir það ekki, getur uppfærsla verið öruggari en að stilla fs: false. Einnig, að skipta Node-hugsaðri pakka fyrir einn sem er sérstaklega hannaður fyrir vafra notkun getur minnkað samhæfingar brögð og uppbyggingar flókiðleika.

Veldu þessa leið þegar: óháðin er ætluð til að virka í vöfrum, en uppsetta útgáfan velur eða birtir Node-einkaréttar útfærslu.

Galli: uppfærsla eða skipti á pakka getur kynnt API breytingar, svo keyrðu venjulegu forritaprófin þín frekar en að líta á vel heppnaða þýðingu sem nægilega.

Valkostur 5: Ef úttakið er Node uppbygging, stilltu markmiðið á Node

Stundum er Webpack ekki að framleiða vafra kóða yfirleitt. Þú gætir verið að pakka CLI, bakgrunns vinnara, byggingarverkfæri, SSR netþjón, eða Node þjónustu. Í því tilviki, að reyna að þagga niður í fs er baklengs: keyrslutíminn veitir það í raun.

Opinber Targets skjölun Webpack segir að:

module.exports = {
  target: 'node'
}

þýði fyrir Node.js-líkt umhverfi og skilji innbyggðar einingar eins og fs og path eftir fyrir Node að veita í keyrslutíma.

Nánari target stillingar tilvísun Webpack greinir einnig á web, node, Electron markmið, vafra vinnara, og önnur umhverfi.

Notaðu target: 'node' þegar: niðurstaðan JavaScript keyrir undir Node.

Ekki notaðu það til að “laga” venjulega vafra SPA: að breyta markmiðinu gerir ekki vafra skyndilega veita Node skráakerfis API. Það breytir hvaða umhverfi Webpack gerir ráð fyrir að keyri uppbygginguna.

Ítarlegar Node byggingar: externals geta haldið innbyggðum einingum í keyrslutíma

Fyrir netþjóns uppbyggingar, veitir Webpack einnig Node-hugsaða externals hegðun. Opinber Externals skjölun segir að externalsPresets.node geti meðhöndlað Node innbyggðar einingar eins og fs, path, og vm sem ytri og hlaðið þær með Node keyrslutíma require().

Typísk Node-hugsað stilling gæti því litið svona út:

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

Þetta er ítarlegt netþjóns uppbyggingar málefni, ekki vafra workaround.

Skref 4: Endurbyggðu, prófaðu síðan eiginleikann sem olli innflutningnum

Eftir að hafa gert arkitektúr eða stillingarbreytinguna, endurbyggðu:

npm run build

Hrein þýðing sannaðir aðeins að einingaleysti tókst. Það sannar ekki að sá eiginleiki hegði sér rétt. Prófaðu samkvæmt lagfæringunni sem þú valdir:

• Ef þú fluttir skráaaðgang yfir á netþjón, kallaðu á vafra eiginleikann og staðfestu að netþjón endapunkturinn skili væntanlegum gögnum.
• Ef þú stilltir fs: false, keyrðu óháðina í vafra og staðfestu að hún fari aldrei inn í skráakerfis-háða greinina.
• Ef þú skiptir yfir í vafra byggingu pakka, keyrðu raunverulegt notenda-væntanlegt vinnuflæði pakka.
• Ef þú breyttir markmiðinu í Node, keyrðu byggt úttak undir Node útgáfunni sem þú styður.

Algengar lagfæringar samanburðar

Sértilfelli: sameiginlegur kóði fluttur inn af bæði vafra og netþjóns uppbyggingum

Algeng uppspretta þessarar villu er hjálparforrit eining sem inniheldur bæði hreinar föll og Node-einkaréttar hjálparforrit:

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

Jafnvel þótt vafrið þitt flytji inn aðeins formatDate, getur efsta stigs fs innflutningur þvingað Webpack að leysa fs. Hreinna hönnun er að skipta einingunum:

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

Þetta gerir keyrslutíma mörkin sýnileg í einingagrafinu í stað þess að treysta á tree-shaking eða fallback til að fjarlægja ósamanhæfanlegan innflutning.

Sértilfelli: villan kom fram eftir uppfærslu frá Webpack 4

Þetta er eitt af klassískum Webpack 5 flutnings einkennum. Webpack 4 veitti sjálfkrafa samhæfingar shims fyrir margar Node kjarnaeiningar. Webpack 5 hætti við það viljandi. Ef kóðinn þinn “virkaði áður en uppfærslan”, spurðu hvort hann þurfti virkilega Node eiginleikann í vafra eða hvort gamli pakkarinn sprautuði inn samhæfingar kóða þagnandi.

Opinbera Webpack flutningsleiðbeiningarnar mæla með að lesa brotthætt leiðbeiningar byggingarvillunnar og skipta gömlum node.* samhæfingar stillingum fyrir nýrra leystara nálgun þar sem viðeigandi.

Gerðu ekki ráð fyrir að endurskapa alla Webpack 4 polyfills sé besta flutningurinn. Útgáfunótur Webpack mæla með framenda-samanhæfðum einingum þar sem mögulegt er.

Loka sjálfsprófun

Áður en þú lokar málinu, staðfestu þessa punkta:

1. Finndu nákvæmu upprunaskrána eða óháðina sem flytur inn fs.
2. Staðfestu hvort sá uppbygging keyrir í vafra eða í Node.
3. Ef það er vafra uppbygging, staðfestu hvort eiginleikinn þarft virkilega skráakerfis hegðun.
4. Ef hann gerir það, færa skráakerfis aðgerðina á bak við netþjóns mörk.
5. Ef fs notkun óháðarinnar er valkvæð og keyrir aldrei í vafra, íhugaðu resolve.fallback: { fs: false }.
6. Ef pakkin veitir opinberlega vafra útflutning, kjósaðu það frekar en að þagga niður í nauðsynlega hegðun.
7. Ef uppbyggingin keyrir í Node, notaðu Node markmið í stað vef markmiðs.
8. Endurbyggðu og staðfestu að einingaleysti villan er horfin.
9. Keyrðu raunverulega eiginleikann sem áður dró inn fs; ekki stoppa við “þýddist vel”.

Varanlega lagfæringin er að samræma kóðann við keyrslutíma sinn. fs tilheyrir Node skráakerfis umhverfinu. Webpack 5 gerir þau mörk sýnilegri með því að ekki lengur sprauta inn Node kjarna polyfills sjálfkrafa. Þegar þú hefur ákveðið hvort skráakerfis vinnan tilheyrir netþjóni, er valkvæð í vafra, eða er hluti af Node-markmiðaðri uppbyggingu, verður rétta stillingin mun auðveldari að velja.