Failed to parse source map: fix the missing src warning

TL;DR#

The warning comes from source-map-loader, which react-scripts 5 runs on every JavaScript file, including those in node_modules. A package ships a .map file whose sources list points to files such as ../src/components/Button/Button.tsx, but the map has no embedded source text and the package does not publish its src folder. The loader tries to open the file, gets ENOENT, and emits a warning; the app still builds and runs. The real fix belongs to the package: publish maps that carry sourcesContent (TypeScript inlineSources), or publish the files the map names. As the consumer, ignore that one warning precisely. GENERATE_SOURCEMAP=false also removes it, but it switches off more than the warning.

The message from the Stack Overflow question, where the asker had built @AAA/BBB with Rollup and installed it in a React app:

Failed to parse source map from 'C:\Users\XXXX\Desktop\example\node_modules\@AAA\BBB\src\components\Button\Button.tsx' file:
Error: ENO ENT: no such file or directory, open
'C:\Users\XXXX\Desktop\example\node_modules\@AAA\BBB\src\components\Button\Button.tsx'

The same warning was reproduced on 22 October 2026 in the official node:22-alpine Docker image (Node 22.23.3) with webpack 5.112.0 and source-map-loader 3.0.2, the major version react-scripts 5 depends on. The webpack config copied the source-map-loader rule from the react-scripts 5 webpack config verbatim; react-scripts itself was not installed. The library was a hand-written dist/index.js whose map names a source that is not shipped:

{"version":3,"file":"index.js","sources":["../src/components/Button/Button.tsx"],"names":[],"mappings":"AAAA;AACA;AACA"}

WARNING in ./node_modules/@aaa/bbb/dist/index.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/tmp/app/node_modules/@aaa/bbb/src/components/Button/Button.tsx' file: Error: ENOENT: no such file or directory, open '/tmp/app/node_modules/@aaa/bbb/src/components/Button/Button.tsx'
 @ ./src/index.js 1:0-34 2:12-18

webpack 5.112.0 compiled with 1 warning

The same warning appeared with source-map-loader 5.0.0, the current latest tag on npm.

Why it happens#

The Create React App changelog lists, under the 5.0.0 release of 14 December 2021, "Add source-map-loader for debugging into original source of node_modules libraries that contain sourcemaps" (PR #8227). That is why the warning showed up for many projects right after the move to react-scripts 5, and why react-scripts 4, whose package metadata on npm lists no source-map-loader dependency, never printed it. The relevant lines of that config, trimmed to an excerpt:

const shouldUseSourceMap = process.env.GENERATE_SOURCEMAP !== 'false';
 
const rules = [
  // Handle node_modules packages that contain sourcemaps
  shouldUseSourceMap && {
    enforce: 'pre',
    exclude: /@babel(?:\/|\\{1,2})runtime/,
    test: /\.(js|mjs|jsx|ts|tsx|css)$/,
    loader: require.resolve('source-map-loader'),
  },
  // ...the other rules
];

For each file that ends with a sourceMappingURL comment, the loader reads the map and walks its sources array. In source-map-loader's index.js, a source is only skipped when the map already carries its text in sourcesContent. Otherwise the loader resolves the path relative to the map and reads it from disk; when that read fails, utils.js throws the error you see, and index.js passes it to emitWarning. That is why webpack still says the build succeeded and the button still works: nothing in the bundle is missing, only the original source for the debugger.

So the defect is in what the package published, not in your app. A library built with files: ["dist"] in its package.json ships dist/index.js and dist/index.js.map, while the map still points one folder up, into a src that never left the author's machine.

The full chain was reproduced with a real library build. Rollup 4.65.0 with @rollup/plugin-typescript 12.3.1 and TypeScript 5.9.3, sourceMap: true and inlineSources: false in tsconfig.json, and "files": ["dist"] in the library's package.json:

--- dist/index.js.map with inlineSources false:
{"sources":["../src/components/Button/Button.tsx"],"sourcesContent":[null]}
--- published tarball contents (files: [dist]):
126B dist/index.js
208B dist/index.js.map

The map names ../src/components/Button/Button.tsx, its text is null, and the tarball carries no src folder. Consumed by the same webpack config, that build printed the warning again.

Fix#

Pick the step that matches your role. If you publish the package, fix the package; every consumer benefits. If you only consume it, step 3 hides that one warning and nothing else.

1. Library author: embed the source text in the map#

The TypeScript inlineSources reference says: "When set, TypeScript will include the original content of the .ts file as an embedded string in the source map (using the source map's sourcesContent property)." It needs sourceMap (or inlineSourceMap) as well:

{
  "compilerOptions": {
    "sourceMap": true,
    "inlineSources": true
  }
}

Rebuilding the same Rollup library with that one change produced a map that carries the text:

--- dist/index.js.map with inlineSources true:
{"sources":["../src/components/Button/Button.tsx"],"sourcesContent":["export function Button(label: string): string {\n  return \"<button>\" + label + \"</button>\";\n}\n"]}

and the consuming build went clean:

webpack 5.112.0 compiled successfully

On the Rollup side, keep the output option sourcemapExcludeSources at its default (false). The Rollup docs describe the true setting: "If true, the actual code of the sources will not be added to the sourcemaps, making them considerably smaller."

2. Library author, alternative: publish the files the map names#

If you prefer small maps, publish the sources next to dist:

{
  "name": "@aaa/bbb",
  "main": "dist/index.js",
  "files": ["dist", "src"]
}

In the repro, adding src/components/Button/Button.tsx to the installed package, with the original map left untouched, also ended the warning (compiled successfully). Either way, run npm pack --dry-run before publishing and check that every path in the map's sources either has text in sourcesContent or appears in the tarball.

3. App owner: ignore this warning for node_modules only#

webpack 5 has an ignoreWarnings option that filters warnings by module and message. Scope it to node_modules so the same message from your own code still shows:

// webpack.config.js
module.exports = {
  // ...the rest of your config
  ignoreWarnings: [
    { module: /node_modules/, message: /Failed to parse source map/ },
  ],
};

With the same broken library installed, that build printed no warning block:

webpack 5.112.0 compiled successfully

source-map-loader still marks the module with [1 warning] in the module list; the warning is filtered from the output, not prevented. In a plain react-scripts project you cannot edit the webpack config without ejecting or using a config-override tool. A pull request that adds exactly this kind of filter to react-scripts (#11752) is still open, not merged.

4. What GENERATE_SOURCEMAP=false really switches off#

The top answer on the question, GENERATE_SOURCEMAP=false in .env, works, and the config shows why. shouldUseSourceMap is process.env.GENERATE_SOURCEMAP !== 'false', and it gates the source-map-loader rule in every mode, so the loader never runs. scripts/start.js loads config/env (which reads .env) before it builds the webpack config, so the .env file is enough.

It also changes more than the warning:

• Development (npm start): the app's own devtool stays cheap-module-source-map, and the Babel loader for your src folder has no source-map switch, so your own code keeps its maps. What you lose is debugging into node_modules: the loader that reads library maps is gone, and the Babel loader for code outside src gets sourceMaps and inputSourceMap set to false.
• Production (npm run build): devtool becomes false, so no .map files are written for your app either.

The CRA advanced configuration table marks the variable as ignored in development and says: "When set to false, source maps are not generated for a production build. This solves out of memory (OOM) issues on some smaller machines." The config file shows it does act in development, on the source-map-loader rule. If a build really runs out of memory, the heap limit page shows how to raise the V8 heap cap of the process that died instead of dropping source maps.

A negative control confirms that it is the loader rule, not your app's maps, that matters: turning off the app's own devtool while keeping the loader rule left the warning in place (compiled with 1 warning).

Verify the fix#

To find which installed package ships a broken map, list every map source that has neither embedded text nor a file on disk:

// find-missing-sources.js
const fs = require('fs');
const path = require('path');
 
const root = process.argv[2] || 'node_modules';
 
function walk(dir, out) {
  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
    const full = path.join(dir, entry.name);
    if (entry.isDirectory()) walk(full, out);
    else if (entry.name.endsWith('.map')) out.push(full);
  }
  return out;
}
 
for (const mapFile of walk(root, [])) {
  let map;
  try {
    map = JSON.parse(fs.readFileSync(mapFile, 'utf8'));
  } catch {
    continue;
  }
  const base = path.resolve(path.dirname(mapFile), map.sourceRoot || '');
  (map.sources || []).forEach((source, i) => {
    const hasContent = map.sourcesContent && map.sourcesContent[i] != null;
    const onDisk = fs.existsSync(path.resolve(base, source));
    if (!hasContent && !onDisk) {
      console.log(`${mapFile}: missing ${source}`);
    }
  });
}

Pass it node_modules to scan everything, or one package folder. On the broken library (node find-missing-sources.js node_modules/@aaa/bbb) it printed one line:

node_modules/@aaa/bbb/dist/index.js.map: missing ../src/components/Button/Button.tsx

After a library fix, every source in the map either has text or exists on disk, so the script has nothing to print for that package, and the build compiles without the warning block, as in the Rollup run above. After the ignoreWarnings fix, the script still lists the package (the map is unchanged) while the build output is clean, which is the expected difference between fixing and filtering.

The scripts answer that sets nothing#

The second answer suggests "start": "GENERATE_SOURCEMAP=false && react-scripts start". In a POSIX shell, an assignment followed by && is a separate command that sets a shell variable without exporting it, so the next process does not see it. Under sh in the repro container:

### step 6: shell assignment chained with && (answer 2 form) does not reach the child process
undefined
false

The first line is the && form, the second is GENERATE_SOURCEMAP=false node … without &&. Use the .env file, the form without &&, or the cross-env package if the same script must also run under Windows cmd.exe (the heap limit page shows how npm picks the shell).

Vite prints a different warning for the same map#

Vite does not use source-map-loader, so the webpack message never appears there. Vite 8.3.5 was tested with the same broken library:

• By default the dependency is pre-bundled, and the pre-bundled file's map pointed to dist/index.js with its text embedded. No warning was printed.
• With the package excluded from pre-bundling with optimizeDeps.exclude set to ['@aaa/bbb'], Vite served the file as-is and its injectSourcesContent logged:

Sourcemap for "/tmp/vapp/node_modules/@aaa/bbb/dist/index.js" points to missing source files

The cause and the library fix are the same. Vite's source suggests running with DEBUG="vite:sourcemap" to list the missing paths.

The react-scripts 4 downgrade trap#

If you downgraded to react-scripts 4 to get rid of the loader (one of the options the third answer lists and rejects), note that react-scripts 4 pins a webpack 4 release (see its npm metadata). On Node 17 or later that combination fails with error:0308010C:digital envelope routines::unsupported, so the downgrade trades a harmless warning for a broken build. The third answer's own idea, rewriting node_modules/source-map-loader/dist/utils.js on every start, stops working as soon as source-map-loader changes the message text, as that answer itself warns.

Checking npm pack --dry-run against the map's sources before each release prevents this warning, and it is the one fix that removes it for every app that installs the package, not only yours. Two other errors that also start in node_modules have different causes and are not caught by that check. Vite's [commonjs--resolver] Failed to resolve entry means a package.json points to a file that does not exist on disk, often in a broken nested copy of a package on the consumer side. ERR_PACKAGE_PATH_NOT_EXPORTED means the package's exports map has no entry for the subpath you import, or lists it only under the "import" condition while you load it with require().