Currently, Modulator is the single abstraction of setting objects used for module script loading and execution.
However, there are multiple concepts of settings objects within a Modulator (at least a fetch client settings object and a module map settings object, which don't correspond one-to-one in worker cases), so it would be better to split Modulator into smaller interfaces each of which represents a specific spec concept.
Modulator was introduced not to expose the full interface of ExecutionContext to the module script system, because ExecutionContext is a too rich interface exposing much more things.
So the rough plan here is (1) introduce settings object intrerface classes (each of which would expose a subset of ExecutionContext capability) and (2) replace Modulator with those smaller interfaces.
Comment 1 by hirosh...@chromium.org
, May 21 2018