Safe JavaScript Module Plan


Mark S. Miller, Darya Melicher, JF Paradis and I have been writing up a plan for Safe JavaScript Modules. It’s still a work in progress, but please feel free to comment or make suggestions. The basic idea is this:

  1. 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.
  2. 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.
  3. Use a package manifest similar to package.json to describe the relationships among packages in a declarative manner.
  4. 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.


We’ve simplified our approach in a major way. Now, there are only manifests and authority-handling modules that can subdivide, attenuate, or virtualize an application’s authority. I’m rewriting the doc now in light of this, but I can say it’s much easier to understand.