** Edit as of March 21: our plan has changed somewhat from the original plan, and we’ve moved the document to a github repo. Updated description below:
- 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.
- Write attenuating modules to limit the authority of the modules to only what is necessary. In the example that we use in the document, the package
supports-colorimports the built-in
osmodule, but it doesn’t really need most of the features of
os, like the ability to set the scheduling priority of any process (!). It only uses the
osmodule to get the current platform and release. Therefore, the attenuating module will provide an
supports-colorthat is limited to just giving the current platform and release and not all of the other abilities.
- If necessary, use a package manifest similar to package.json to describe the relationships among modules (including the attenuating modules) in a declarative manner.