** 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:
Mark S. Miller, Darya Melicher, JF Paradis and I have been writing up a plan for Safe JavaScript Modules (old link to google doc). It’s still a work in progress, but please feel free to comment or make suggestions. The basic idea is this:
- 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.
fs
in 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-color
imports the built-inos
module, but it doesn’t really need most of the features ofos
, like the ability to set the scheduling priority of any process (!). It only uses theos
module to get the current platform and release. Therefore, the attenuating module will provide anos
tosupports-color
that 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.