After Upgrading to CRA 5.0 getting a lot of: Failed to parse source map from

[jessemlay]

Upgraded and now I'm getting a lot of Failed to parse source map from warnings. How can I resolve or just ignore these ?

[KmaCoder]

To ignore the warning you can disable sourcemap generation via setting env var GENERATE_SOURCEMAP to false (#11278 (comment))

But I'm also curios if this should be ignored or fixed somehow

[kidwm]

you can just ignore them, it would not make CI failed when builds.

[pzapo]

I got the same problem from upgrading CRA 3.4.3 to 5.0.0.

[Manubi]

Is there a proper fix or just ignore?

[MarcStdt]

I have the same problem. Is there a way to get around this?

[aleexnl]

There's a PR open #11752. There's no estimated time for the 5.0.1 release so, until that just ignore.

[marsen]

How to ignore it?

[aleexnl]

To ignore the warning you can disable sourcemap generation via setting env var GENERATE_SOURCEMAP to false

[lanwin]

The best solution is to open a issue or pullrequest on that packages.

The warnings are correct. These packages source maps pointing to src that is not included in the package. The solution would be to remove source maps from the package or add the src at the location the source maps pointing to.

[mbganesh]

I have the same problem, and why its happened?

[SamKiwi2021]

a simple solution:

 "scripts": {
        "start": "GENERATE_SOURCEMAP=false react-scripts start",

More on the link below:

mswjs/msw#1030 (comment)

[mikocot]

exactly I dont understand how people even consider this a solution, while it seems to be an accepted answer everywhere! It's like you turned off brakes in your car, cause you've got an ABS warning

[pulkit2910-bit]

It does not work for me can you please provide another solution for this

[shubham-kumar-sinhas]

worked for ignore the problem.

[Laszlo-Gyory]

You are a genius

[nky1047]

Facing similar issue with BootStrap File

[oshi97]

does anybody have an explanation for exactly what is wrong with the node module source maps like in this example? my team manages an open source library and I'm trying to figure out whether (or more likely, how) we've messed up our source maps

[oshi97]

The issue appears to be not tracking the "src" directory (or wherever your source files go) in your npm package with the "files" package.json property, for say a typescript library that has a compilation step.

[faizalkautsar]

hi. I have the same issue here. what should I do to resolve this issue? I only have dist in my files property in package.json because I do not want to include the source code in the client.

[oshi97]

You need to include source code in your npm package for source maps to work. If you don't want to do that you should probably stop building source maps as well

[otariterterashvili]

Does anyone fix it ?

[DavidArmendariz]

I also want to know how to fix this.

[ghost]

Some enlightenment.

This happens to me when using a personal-component-library.

Look at this warning message:

WARNING in ./node_modules/@stephyswe/test-kit/dist/utils/ArrayHelper.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from 'D:\Dev\v9\complib\alex-app\node_modules\@stephyswe\test-kit\src\utils\ArrayHelper.ts' file: Error: ENOENT: no such file or directory, open 'D:\Dev\v9\complib\alex-app\node_modules\@stephyswe\test-kit\src\utils\ArrayHelper.ts'
 @ ./node_modules/@stephyswe/test-kit/dist/index.js 45:0-51 45:0-51
 @ ./src/App.tsx 5:0-45 12:37-43
 @ ./src/index.tsx 6:0-24 10:33-36

In my package there is three files for "ArrayHelper" in the dist folder.

ArrayHelper.js.map
ArrayHelper.d.ts
ArrayHelper.js

generated from the original file src/utils/ArrayHelper.ts

But for some reason CRA wants the .ts file too.

.................................

( Source Code ) Just for details, here are the source code for all files.

ArrayHelper.ts

/* eslint-disable import/prefer-default-export */
const stockFill = (index: number) => index;

export const fillArray = <T>(
  count: number,
  callback: (index: number) => unknown = stockFill,
): T[] => new Array(count).fill(null).map((_, i) => callback(i)) as T[];

in the dist folder.

ArrayHelper.d.ts

export declare const fillArray: <T>(count: number, callback?: (index: number) => unknown) => T[];

ArrayHelper.js

var n=function(n){return n},r=function(r,t){return void 0===t&&(t=n),new Array(r).fill(null).map((function(n,r){return t(r)}))};export{r as fillArray};
//# sourceMappingURL=ArrayHelper.js.map

ArrayHelper.js-map

{"version":3,"file":"ArrayHelper.js","sources":["../../src/utils/ArrayHelper.ts"],"sourcesContent":[null],"names":["stockFill","index","fillArray","count","callback","Array","fill","map","_","i"],"mappings":"AACA,IAAMA,EAAY,SAACC,GAAkB,OAAAA,GAExBC,EAAY,SACvBC,EACAC,GACQ,YADR,IAAAA,IAAAA,EAAgDJ,GACxC,IAAIK,MAAMF,GAAOG,KAAK,MAAMC,KAAI,SAACC,EAAGC,GAAM,OAAAL,EAASK"}

....................................................

Umm, looking at my own example. I decided to remove sourcemaps from rollup. And that make the issue in CRA go away too.

rollup.config.js

output: {
    dir: 'dist',
    format: 'esm',
    preserveModules: true,
    preserveModulesRoot: 'src',
    sourcemap: false, <- was true before
  },
```

[ghost]

Some enlightenment.

This happens to me when using a personal-component-library.

Look at this warning message:

WARNING in ./node_modules/@stephyswe/test-kit/dist/utils/ArrayHelper.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from 'D:\Dev\v9\complib\alex-app\node_modules\@stephyswe\test-kit\src\utils\ArrayHelper.ts' file: Error: ENOENT: no such file or directory, open 'D:\Dev\v9\complib\alex-app\node_modules\@stephyswe\test-kit\src\utils\ArrayHelper.ts'
 @ ./node_modules/@stephyswe/test-kit/dist/index.js 45:0-51 45:0-51
 @ ./src/App.tsx 5:0-45 12:37-43
 @ ./src/index.tsx 6:0-24 10:33-36

In my package there is three files for "ArrayHelper" in the dist folder.

ArrayHelper.js.map
ArrayHelper.d.ts
ArrayHelper.js

generated from the original file src/utils/ArrayHelper.ts

But for some reason CRA wants the .ts file too.

[ioloie]

If you're like me and using the craco (@craco/[email protected]) then the following in my craco.config.js worked for me

module.exports = {
  webpack: {
    configure: {
      ignoreWarnings: [
        function ignoreSourcemapsloaderWarnings(warning) {
          return (
            warning.module &&
            warning.module.resource.includes("node_modules") &&
            warning.details &&
            warning.details.includes("source-map-loader")
          );
        },
      ],
    },
  },
};

[hcharley]

Thank you!

[joselmarianocreateape]

Not working on my end, is there anything else that has been done?

• I have installed "@craco/craco": "^7.1.0",
• copy pasted this very craco config
• yarn started ( using nodejs 20 )

[anonimitoraf]

What's your start script?

[joselmarianocreateape]

Hi @anonimitoraf,. thanks for the reply
here are the snippets

• package.json

  "scripts": {
    "start": "craco start",
    "build": "craco build",
    "test": "craco test --passWithNoTests",
    "eject": "react-scripts eject"
  },
  "dependencies": {
    "@craco/craco": "^7.1.0",

• craco.config.js ( I'm trying to experiment with the devtool values as well )

module.exports = {
  webpack: {
    configure: {
      devtool: 'eval-cheap-module-source-map',
      ignoreWarnings: [
        function ignoreSourcemapsloaderWarnings(warning) {
          return (
            warning.module &&
            warning.module.resource.includes('node_modules') &&
            warning.details &&
            warning.details.includes('source-map-loader')
          )
        },
      ],
    },
  },
}

Could you let me know what have I been doing wrong? I'm running it via command yarn start

[dreamstyle]

@joselmarianocreateape That's what I did and it works well:

1. yarn add -D @craco/craco (7.1.0)
2. create craco.config.js and paste the config above
3. update package.json

"scripts": {
  "start": "craco start"
}

4. yarn start

I'm using node 16.

Did you try this one and see any console messages?

{
  "scripts": {
    "start": "craco start --verbose"
  }
}

[Minho-Lee]

Getting the same issue for use-debounce package (upgraded it to the latest version as well - 8.0.1).

ERROR in ./node_modules/use-debounce/esm/index.js
Module build failed (from ./node_modules/react-scripts/node_modules/source-map-loader/dist/cjs.js):
Error: ENOENT: no such file or directory, open '/Users/minholee/code/yaro/node_modules/use-debounce/esm/index.js'

[Minho-Lee]

This is no longer the case for use-debounce.

[donhuvy]

You can use temporary solution at https://stackoverflow.com/questions/36051891/esri-failed-to-parse-source-map/70975790#70975790 .

Add .env to your root folder of your project

GENERATE_SOURCEMAP=false

[niron1]

why would I want to disable source maps for 1000 libraries when only 1 gives the error ?

[ipmcc]

Lots of folks here seem to be suggesting setting GENERATE_SOURCEMAP=false or changing the output settings to turn off sourceMaps. Forgive my ignorance if I'm misunderstanding this, but won't turning off sourceMap generation remove your ability to debug your own code?!

If some package in node_modules didn't ship a sourceMap (as indicated by the ENOENT: no such file or directory part of the message) that sucks, but all it means for debugging is that I just won't be able to step into that module in any sane way, but I don't want to just turn off sourceMap generation altogether! I'd still like to generate sourceMaps for my own code so I can debug it, and also to be able to step into any modules that do ship with source and sourceMaps in the debugger.

There ought to be some way to say "If you can't find the sourceMap, and you were looking in node_modules, don't bother telling me."

[Askadias]

The best comment IMHO ))

[aleexnl]

This should be the discussion answer.

[Mazuh]

I totally agree, just some flag to enable source maps only for my src would be great.

[niron1]

thank you for writing that.

[alishi973]

is this means no one has fixed this issue and we must ignore the warning all the time?

[anonimitoraf]

For anyone else using react-app-rewired to override webpack without having to eject, placing this in my config-overrides.js seems to work

module.exports = function override(config) {
  return {
    ...config,
    ignoreWarnings: [
      {
		// Change this to fit your needs
        module: /node_modules\/@codetrix-studio\/capacitor-google-auth/,
      },
    ],
  }
}

As @ipmcc stated, I think GENERATE_SOURCEMAP=false is way too drastic of a solution (unless you don't care about having any source maps at all)

[cheeyang]

This was the most sane answer for me, instead of turning off source map generation across the board.

For anyone else looking for a solution which will still allow you to debug your code, and ignore ONLY the source map warning for any installed library, this is what I went with in the end:

module.exports = function override(config) {
  return {
    ...config,
    ignoreWarnings: [
       module: /node_modules/,
       message: /Failed to parse source map/,
    ],
  }
}

[steezeburger]

You're missing curly braces

module.exports = function override(config) {
  return {
    ...config,
    ignoreWarnings: [{
       module: /node_modules/,
       message: /Failed to parse source map/,
    }],
  }
}

[anabwan]

Just keep the source folder with the dist/ lib this will solve the issue

[figuratively]

@MarcStdt @otariterterashvili @ipmcc I have an ugly solution but it allows you to keep your existing source maps and suppress these warnings without using react-app-rewired, cracko or GENERATE_SOURCEMAP=false.

You can create a script like so:

const { readFileSync, writeFileSync } = require("fs");

const path = "node_modules/source-map-loader/dist/utils.js";
const regex = /.*throw new Error\(`Failed to parse source map from '\${sourceURL}' file: \${error}`\);*/;

const text = readFileSync(path, "utf-8");
const newText = text.replace(regex, `buffer="";sourceURL="";`);
writeFileSync(path, newText, "utf-8");

and then add it to your package.json:

  "scripts": {
    "start": "node scripts/removeSourceMapsWarning.js && react-scripts start"

Obviously this code will stop working when source-map-loader changes the error message. But I hope we will a real solution for it by then.

[paulfelix]

I recommend that CRA maintainers add an "ignoreWarnings" entry to webpack.config.js as described in the source-map-loader README.md:

ignoreWarnings: [/Failed to parse source map/],

Maybe it could be added if some new env variable is set or not set.

For now, you can take the @figuratively script and turn it into a postinstall script that modifies webpack.config.js as part of the installation:

const { readFileSync, writeFileSync } = require("fs");

const path = "node_modules/react-scripts/config/webpack.config.js";
const text = readFileSync(path, "utf-8");

if (!text.includes("ignoreWarnings:")) {
  const stats = "stats: 'errors-warnings',";
  const newText = text.replace(stats, `${stats} ignoreWarnings: [/Failed to parse source map/],`);
  writeFileSync(path, newText, "utf-8");
}

[paulfelix]

This code only adds the ignoreWarnings setting if it does not exist in the config file.

[siaikin]

This discussion has been open for a year and has 94 votes (which seems to be the most votes), yet the author chooses to ignore it.

[siaikin]

let's use vite. reactjs/react.dev#5487

[xml]

Simply installing your own copy of source-map-loader to the project seems to solve this: npm i -D source-map-loader

[POD666]

It solved the issue for me too.
Feels much better than just disabling the warnings with GENERATE_SOURCEMAP=false.

Why downvoting?
@jamiek-acl, @Emroni, @dominikabieder, @MrAlex475, @garyb01, @VincentRacine-UnlikelyAI, please explain 🙏

[Omkar-Jawalkar]

@xml, is their any disadvantage for installing the own copy of source-map-loader to the project?

[juanmagalhaes]

I'm not sure this is related but I was noticing recently that the Errors in the Dev/Local Error Modal were displaying very bad error messages without a proper source map setup.

I went to do a sanity check to make sure it wasn't specific to my project cause I have a small set of Craco configs in it and so I created a fresh CRA project using react-scripts 5.0.1, no templates. I ran the start script already got some warnings on the console, babel related and some webpack-dev-server related:

But I don't think those are related to this issue. Then I went to test how the errors would show to me and I forced an error by adding in the App.js component:

function App() {
  var x = {}
  console.log(x.a.b)
  return (

And here is the result:

Seems like the source maps are doing alright on the DevTools but def not on the Error Modal

[erosval]

use "vite" and solve the underlying problem

[sumitkumarindiit]

in my case it fixed by adding GENERATE_SOURCEMAP=false in .env file

[ipmcc]

If you look at my earlier comment here you'll see an explanation of why this is not a viable solution. If it works for you, great! But it doesn't work at the broader application development level.

[alexm92]

Any progress on this?
I started seeing these warnings after upgrading to "@headlessui/react": "^2.0.3", using "react-scripts": "5.0.1"

[ipmcc]

This issue is years old. It's been well-described, in detail, and several possible, practical solutions have been explained (not the least of which by me, further up this thread.) It's clearly not a priority for anyone involved.

What I've learned over the years is that hermetic, error-, and warning-free builds are simply not considered valuable to the JS community. Not even a little bit. Similarly, despite being a different issue, source-level debugging is not considered to be a valuable feature worthy of ongoing support -- libraries that break it are often entirely unrepentant. I went into some detail about one particular instance over here.

It'd be very cool if these issues got fixed, but it's a little bit like the parable about 'the frog and the scorpion': JS app developers are the frogs, and JS library/infrastructure developers are the scorpions. They think, "It solves my problem, because XYZ (...like, I use console.log to debug; so no problem, it works for me!!); I don't give a flying f*ck if it helps or hurts you (the app developer consuming my library)." I get that library developers won't get their panties in a bunch every time someone complains about their library, but things that prevent hermetic builds and break source-level debugging? Those are parts of the reason I'll avoid ever having to use this ecosystem again, if at all possible, which is, frankly, a shame since, fundamentally, I don't mind the language, and appreciate its ubiquity, etc.

But let's be honest: This is the developer ecosystem that gave us things like the leftpad incident. That might very well be the dumbest thing that has ever happened in modern software development, but the willingness to break source-level debugging, and the willingness to ship software that prevents hermetic, error-, and warning-free builds contributes to why, despite its ubiquity, developers coming from 'serious' environments are frequently disgusted by the modern JS development scene, and stay away from it.

I've bowed out of JS development at this point, and hope to never return, but my advice to you is: Don't hold your breath. Fixing this will require effort from a number of people, a large portion of who, if history is any indicator, couldn't give half a rat's ass if their code cripples everyone else in the ecosystem.

[sanketjanjarukiya]

Same issue is here while using intro.js and intro.js-react library in my react typescrit project.

I did some changes in my webpack-rtl.config.js file but nothing happened.