feat(endo): Add assemble

[kriskowal]

The compartment assembler takes a compartment map and builds the
corresponding compartment instances, feeding the modules exported by
each dependency into the dependee compartment's module map.

[warner]

I'm guessing this branch pointer needs to be reset to something descending from endo-search? I'll study the one file (assemble.js) as it is in this branch for now. (I see that the file is the same, so hopefully the rebase should be easy).

[warner]

I only looked at assemble.js, because I'm assuming this branch needs to be re-sewn into the main sequence of PRs (and the other files are covered by other PRs), but it looks good to me.

[warner]

This name is the same as packageLocation in compartmap.js, right? And it's not the label from that data structure. And I think it's nominally a URL (although compartments[name].root, which happens to be a copy of name, is probably more deserving of an identifier which has "location" in the name since I think that .root will be used to actually find the code).

If the key of compartments is not a load-bearing, I mean, location-bearing identifier, then name is a great parameter name to use. But maybe there's something we could to in compartmap.js to make that clear. Not sure what, maybe:

const translateGraph = (mainPackagePath, graph) => {
  const compartments = {};

  for (const [packageLocation, { label, dependencies }] of entries(graph)) {
  ...
  const name = packageLocation; // not used for location properties, just a distinct name for each compartment
  ...
    compartments[name] = {
      label, // cosmetic, 'packagename@version'
      root: packageLocation, // used to find code for the package

[kriskowal]

The for purposes of assembling compartments, the names are just internal references and are only obliged to be internally consistent. In practice, if the compartment map is prepared by importLocation, they are locations; if the compartment map is prepared by writeArchive, they are unique identifiers. Both of these mechanisms are free to change independent of the assembler.

I can probably make that more clear in code as you’re suggesting.

[warner]

why the fallback? compartmap.js always provides a .module property, right?

[kriskowal]

It does, but left this affordance against the possibility that compartmap.json might be manually manipulated, or that section automatically omitted if empty.

[warner]

The initial caller can pass modules which will be made available to the top-level Compartment, in addition to modules for all of its dependencies (specifically all of the exported modules for all of its dependency packages). Cool. But the dependency modules will shadow any provided by the caller, so this feature couldn't be used for e.g. dependency injection. Is that intentional? I can imagine there's a good reason to do it one way or the other, or maybe even both, but I don't know what those reasons might be.

[kriskowal]

My intent is for this to be usable for dependency injection. I’ll look more closely and will make sure it’s tested.

[kriskowal]

Checked. As written, this is fine for injecting built-in modules that are not declared dependencies, but not for replacing third-party dependencies with overrides.

I think I will land as-is and revisit. I think I want an explicit directive in the compartment map when a package should receive an override. The same mechanism would be used to thread built-in modules expressly to third-party packages and would be driven by policies in package.json or a lavamoat config file.