feat(module-source): Add XS specific variant

[kriskowal]

Closes: #2250
Refs: #2251

Description

Toward using native XS compartments and module sources, this change adds an XS-specific variant of @endo/module-source that patches the native ModuleSource in place instead of entraining Babel. This will allow an XS-specific @endo/import-bundle variant to load both pre-compiled sources (pre-json-mjs) and original ESM sources (mjs).

This change is opt-in, provided the xs runtime condition. These are conditions introduced by Node.js with the node -C development entry.js precedent and supported by @endo/compartment-mapper for both endoScript and endoZipBase64 bundle formats.

Security Considerations

This change increases exposure to a native ModuleSource as implemented in a memory-unsafe language.

Scaling Considerations

We expect a significant improvement in performance at both bundle time and run time upon completion of #2251 since native ModuleSource is considerably faster than a virtualization.

Documentation Considerations

Captured in NEWS.md and README.md.

Testing Considerations

This change introduces a minimal text:xs that runs with xst and is exercised by Continuous Integration. This minimal test can be expanded as we make more progress with the XS-variant of SES, which will allow the virtual Compartment to opt-in to use native ModuleSource.

Compatibility Considerations

The XS-specific shim is not a one-to-one replacement for the Babel implementation and does not support some of the optional arguments. Code that expects these hooks to be called will be dismayed. Despite these limitations, no existing program should break: the xs condition should not be present in any existing application.

Upgrade Considerations

This change will not come to bear on the Agoric chain until after a new version of XS becomes available with a new XS-specific lockdown preamble.

[kriskowal]

Notes from walk thru with @erights:

https://github.com/Moddable-OpenSource/moddable/blob/public/documentation/xs/XS%20Compartment.md#-module-binding

Add assertion to detect the XS bug for import "foo", which should not use { exportAllFrom } bindings.

[erights]

LGTM!

[erights]

Why is this under the # v1.1.0 heading rather than a new # Next release heading?

[kriskowal]

Legitimate error. Thanks.

[erights]

Illegible. Please try something like

Suggested change

	/** @typedef {{ import: string, as?: string, from: string } & { importAllFrom: string, as: string, from: string } & { export: string, as?: string, from?: string } & { exportAllFrom: string, as?: string } & {importFrom: string }} Binding */
	/**
	* @typedef {{ import: string, as?: string, from: string } &
	* { importAllFrom: string, as: string, from: string } &
	* { export: string, as?: string, from?: string } &
	* { exportAllFrom: string, as?: string } &
	* { importFrom: string }
	* } Binding
	*/

. But one that actually works. (I have no idea why the one above does not work.)

[erights]

Actually, it does seem to work for me. Or rather, it doesn't change how the code fails to work under the VSCode interactive type checker:

But both before and after pass yarn lint without even a warning, so I don't know why vscode isn't happy. (Btw, I did restart the TS Server, so it isn't that.)

[mhofman]

It likely needs to be a type union, not a type intersection.

[erights]

I like this approach for adding accessors to an existing object. No change suggested.

[kriskowal]

I’ve addressed all feedback and am holding this back until we like it and #2471 as a set, perhaps even #2593 for stronger validation.