Compartment module map overloads

[Kris Kowal]

I would like to propose a topic for next week, April 27th, provided that we can get both ZB from ConsenSys to present and folks from Moddable in attendance. Please reply if that works for you.

ZB has been working to converge LavaMoat with Endo and one of the next steps is to find a way to thread Node.js built-in modules into a Compartment. We’re pretty sure that the XS position on this is that this should work on Node.js.

new Compartment({}, {fs: 'fs'});

There are a number of problems we’d need to solve to make that work, notably that it’s difficult to reconstruct a module environment record from a module namespace object. We can’t think of a treatment for 'default' that would be universally appropriate.

The next reasonable position to fall-back upon would be something like:

import fs from 'fs';

new Compartment({}, {fs});

This we are closer to being able to do with the SES Compartment shim, but we use an internal brand check to distinguish module exports namespace objects, so the Compartments can address the underlying module environment record given a namespace. So, as long as the namespace object was constructed by a SES shim Compartment, there’s no loss of information. But, you will note in this example, `fs` does not pass that brand-check.

Regardless, I believe we have an open question for the range of valid values for the moduleMap that hinges on how to distinguish its overloads: string, static module record, static module record envelope (for redirect or alias and meta), and module namespace object. The shim can’t distinguish a static module record with a brand check due to practical limitations. I don’t believe either XS or SES shim can brand-check the module record envelope. SES shim uses a brand check for module exports namespaces, but as noted, that has limitations.

ZB has arrived at a solution that works, that involves the use of a Compartment to upgrade arbitrary objects to module namespace objects using the third-party module record API. It works, it gives us an opportunity to program the various appropriate behaviors for the default property which often depend on whether the core module was implemented originally as CommonJS or not.

I’m proposing we get together at the SES meeting to talk through this and get a plan of record written down in a Compartment Proposal issue.

Kris