Open
Bug 1794044
Opened 2 years ago
Updated 2 years ago
Simplify source-map package integration in mozilla-central
Categories
(DevTools :: Debugger, task)
DevTools
Debugger
Tracking
(Not tracked)
NEW
People
(Reporter: ochameau, Unassigned)
References
(Blocks 1 open bug)
Details
There is so many layers between the debugger frontend calling a source map related function and the final code within the source-map package:
- 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
- devtools/client/shared/source-map/index is a generated file, updated when running yarn && node bin/bundle.js in the debugger folder source.
- It is being crafted using webpack, which generated both index.js, worker.js as well as wasm files source, source2
- 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.
- 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•