Bug 1633712 will introduce the first framework code in order to create WorkerTargetActor's via the Watcher Actor. This will focus on the regular web page's workers, running in the web page's process.
Bug 1651518 will followup in order to also support parent process workers and shared workers.
Then, the last step would be to support service workers. Like bug 1651518, it may also be only about tweaking a few filtering methods. The filtering would be slightly more complex for service workers as we might have to filter based on the tab's current origin.
And who knows, it may be more complex than just tweaking a few filtering methods.

The filtering around tab's current origin is being explained over here:
https://phabricator.services.mozilla.com/D77425#2416452
3 options are mentioned.
I would personaly go for option C. I think that it would allow debugging SW in all cases from the debugger and stop having you to have to go through about:debugging in order to debug SW startup/shutdown, which may occur after the page navigated.

Harald told me:

Solution C does indeed seem useful, even though SWs don't react to navigation in any special way (apart from the usual tear down they have after inactivity). Other tools like Console and Network persist data; so showing a SW from a prior domain seems not that bad.

Finally, I think that this isn't strictly necessary for shipping fission.
For now, I'll flag this in the reserve list. But I may be wrong and we can revisit this triage.

Tracking dt-fission-m2-reserve bugs for Fission Beta milestone (M7).

We might want to first change the behavior of SW targets lifecycle via bug 1655439 before implementing this?

Bulk move of all dt-fission-m2-reserve bugs to Fission MVP milestone.

Moving "dt-fission-m3-reserve" bugs to "dt-fission-future" because they don't block Fission MVP.