There is so many layers between the debugger frontend calling a source map related function and the final code within the source-map package:

1. First. The “sourceMaps” object used everywhere in the debugger isn’t any of the many “source map” package we have, but the toolbox SourceMapService source, which is a Proxy on top of the devtools/client/shared/source-map/index module source
2. devtools/client/shared/source-map/index is a generated file, updated when running yarn && node bin/bundle.js in the debugger folder source.
3. It is being crafted using webpack, which generated both index.js, worker.js as well as wasm files source, source2
4. This npm package pull the source-map package as an external dependency source as well the a local dependency, the devtools-wasm-dwarf source. This is where we define the precise version of the source-map package. This also means that the sources isn’t store in m-c.
5. There is yet another indirection within the source-map package. The JS codebase forward most of the calls to the WASM inner implementation. source Which is implemented in another source-map-mappings repo source.

It would be nice to:

• have a unique mozilla-central layer
• have this layer be regular module of devtools (not something crafted by webpack)
• switch worker modules to ESM or at least requirejs modules
• stop having to go through an npm package to use a revision from source-map github repo
• land the Wasm mappings parser into the source-map repo
• review the mozill-central layer and move all the workaround/bugfixes to github!
• vendor source-map package like react, instead or being magically pulled from npm via node bin/bundle.js in the debugger.
• fold wasm specific into source map layer (for now we have two distinct packages in tree)
• try to find the source of the wasm's wasm
• along all these projects, we should drop all custom/magic require path and stick to absolute require path/URL so that we ease the transition to ES modules.