Debugger is frequently implicated in fuzzer-blocking bugs. Its support for Web Assembly evolves slowly, if at all. SpiderMonkey engineers cringe when tracking down a bug leads them into the
Debugger's territory. Even
Debugger's original designers encounter a steady stream of unexpected obstacles when adding support for new ECMAScript features like generators and asynchronous functions.
In any software project, for engineers to be able to accurately estimate the time required to implement a change, certain preconditions must hold:
The features that
Debugger provides must have clear, accurate documentation.
The demands that
Debugger places on the rest of SpiderMonkey in order to implement those features must be documented similarly.
Within the implementation, each component's requirements and promises must be evident to any reasonably skilled developer.
The code must be thoroughly tested.
At the moment, only condition 4) is well in hand. As a result, estimates for
Debugger work have a lot of uncertainty, and it is difficult for new engineers to contribute to the code. To have accurate estimates and a comfortable “bus factor”, we need to invest in refactoring and simplifying the