Error in nodejs: You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize

[arthabus]

I was using source-maps for a bit on my nodejs server and it was working just fine. But now out of a sudden it started to crash with the below error when I try to create a SourceMapConsumer:

Error: You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer
at readWasm (.../myNodeApp/functions/node_modules/source-map/lib/read-wasm.js:8:13)
at wasm (.../myNodeApp/functions/node_modules/source-map/lib/wasm.js:25:16)
at .../myNodeApp/functions/node_modules/source-map/lib/source-map-consumer.js:264:14
at runMicrotasks ()

Is this expected on node? I was never calling the initialize before and it seems like it's only required in browser?

Here is my code snippet:

const sourceMap = require('source-map'); //version "^0.7.3"

let contents = {...} //a json with a valid sourceMap content
let consumer = await new sourceMap.SourceMapConsumer(contents); //<- it now fails here with the above error

I've already tried to revert all my code back to when it was working but the error is still there.

Could anyone point me in the right direction on why this may be happening?

As a note, I've tried to provide the url as it's shown in the web browser usage page but it then fails with "response.arrayBuffer is not a function" internally while it tries to parse the file. I guess that happens because it wasn't able to download the file in the node environment in the first place, but again it seems like the problem is that it shouldn't ask for the url in node at all.

[arthabus]

The problem I've faced was described here:

#349

Basically, the current source-map method of detecting environment is unreliable as it just checks if "fetch" function is declared to decide if it runs in web or in node.

Fixed the problem by switching to beta:

"source-map": "^0.8.0-beta.0",

Hopefully it would be pushed to stable sooner.

[bvaughn]

Just got burned by this as well. Would be nice if this was released in a stable, given how long it's been. (Or that it was at least documented.)

[AntonyFagundez]

If somebody found this bug on cicd. In my team we found a way to fixed it.

In our case v8-to-istanbul@8.1.1 resolve to source-map@0.6.1 but this version breaks on github actions.

---

To resolve it, install it as dev dependency source-map, to resolve to 0.7.4

npm i source-map -D

[agarzola]

In case someone else runs into the issue we ran into recently: We use several packages that depend on source-map, each requiring a different minor version of this package:

Output of yarn why source-map

yarn why v1.22.17
[1/4] 🤔  Why do we have the module "source-map"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "source-map@0.6.1"
info Has been hoisted to "source-map"
info Reasons this module exists
   - Hoisted from "gulp-sourcemaps#source-map"
   - Hoisted from "gulp-sourcemaps#@gulp-sourcemaps#identity-map#source-map"
   - Hoisted from "gulp-concat#concat-with-sourcemaps#source-map"
   - Hoisted from "gulp-sourcemaps#css#source-map"
   - Hoisted from "gulp-autoprefixer#postcss#source-map"
   - Hoisted from "gulp-clean-css#clean-css#source-map"
   - Hoisted from "gulp-uglify-es#terser#source-map-support#source-map"
info Disk size without dependencies: "796KB"
info Disk size with unique dependencies: "796KB"
info Disk size with transitive dependencies: "796KB"
info Number of shared dependencies: 0
=> Found "gulp-stylelint#source-map@0.7.3"
info This module exists because "gulp-stylelint" depends on it.
info Disk size without dependencies: "352KB"
info Disk size with unique dependencies: "352KB"
info Disk size with transitive dependencies: "352KB"
info Number of shared dependencies: 0
=> Found "vinyl-sourcemaps-apply#source-map@0.5.7"
info This module exists because "gulp-clean-css#vinyl-sourcemaps-apply" depends on it.
=> Found "snapdragon#source-map@0.5.7"
info This module exists because "braces#snapdragon" depends on it.
=> Found "terser#source-map@0.7.3"
info This module exists because "gulp-uglify-es#terser" depends on it.
info Disk size without dependencies: "352KB"
info Disk size with unique dependencies: "352KB"
info Disk size with transitive dependencies: "352KB"
info Number of shared dependencies: 0
=> Found "@babel/core#source-map@0.5.7"
info This module exists because "stylelint#@stylelint#postcss-css-in-js#@babel#core" depends on it.
=> Found "@babel/generator#source-map@0.5.7"
info This module exists because "stylelint#@stylelint#postcss-css-in-js#@babel#core#@babel#generator" depends on it.
✨  Done in 0.18s.

You might find, as we did, that simply adding a resolutions object to our package.json to resolve source-map to 0.7.4 (or 0.8.0-beta.0, for that matter) simply creates more problems because packages relying on 0.5.x and 0.6.x versions of source-map break when you try to use 0.7.x. What I didn’t realize for a day or two is that the broken release is 0.7.3, not every pre-0.7.4 release, so instead of resolving source-map to 0.7.4, we had to update our yarn.lock so that all 0.7.x versions are satisfied by 0.7.4 (where before they were satisfied by 0.7.3).

Frankly, I arrived at this solution by accident. After adding the resolutions line to package.json, running yarn install, and noticing the issue I described above, I removed the line and ran yarn install again, and found that we had a passing build. The resulting yarn.lock update looks like so:

 source-map@^0.7.3, source-map@~0.7.2:
-  version "0.7.3"
-  resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.7.3.tgz#5302f8169031735226544092e64981f751750383"
-  integrity sha512-CkCj6giN3S+n9qrYiBTX5gystlENnRW5jZeNLHpe6aue+SrHcG5VYwujhW9s4dY31mEGsxBDrHR6oI69fTXsaQ==
+  version "0.7.4"
+  resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.7.4.tgz#a9bbe705c9d8846f4e08ff6765acf0f1b0898656"
+  integrity sha512-l3BikUxvPOcn5E74dZiq5BGsTb5yEwhaTSzccU6t4sDOH8NWJCstKO5QT2CvtFoK6F0saL7p9xHAqHOlCPJygA==

I hope this helps someone out there spend less time on this issue than I did! 😅

[ericmorand]

So, basically:

• 0.6 definitions are wrong and prevent us from using the SourceNode::children method
• 0.7 is buggy and doesn't work on brower runtimes
• 0.8 has been on beta for...5 years

@loganfsmyth, is this project dead? Should we organize ourselves to take it over?