- Separate the modules into “pure” and “resource” modules. There’s a full definition in the doc, but basically, pure modules don’t have side effects, don’t encompass system resources or resource modules, and don’t contain or transitively reference any mutable state. Resource modules are everything else.
fsin Node.js, for example, would be a resource module.
- Use Realms and SES to load each resource module into its own compartment. Pure modules are much safer and can be loaded together in the root realm.
- Use a package manifest similar to package.json to describe the relationships among packages in a declarative manner.
- Use a “configurator” to express the application’s policy decisions about how top-level packages are wired to each other and how the application’s authority is to be subdivided, attenuated, or virtualized among them. The configurator populate each compartment’s global object and/or global lexical scope with the objects that package instance should be able to access freely. Because some of these are interesting attenuations or virtualizations, this cannot be expressed purely declaratively but must be able to contain code.