This introduces an XS-specific variant on the SES and StaticModuleRecord packages and includes a suite of parity tests for ensuring equivalent behaviors between Node.js and XS.
The compatible flavor of XS is very specific. Endo’s Compartment Mapper provides a Rollup-analogue bundler that respects Node.js’s conditional imports and generates a single script we can run under xst and could use to bootstrap xsnap. To use these XS contingent variants on SES and StaticModuleRecord, we must use Endo’s bundler with the "xs" tag.
Security Considerations
We must take care to ensure that our parity tests cover (or at the very least spot-check) all the security properties of SES.
Scaling Considerations
We expect considerable performance improvement using XS-specific SES shim and ModuleSource variants on XS and other improvements to ecosystem health in general, discussed in #400.
Using an XS-specific variant of SES and StaticModuleRecord makes it possible to even contemplate bundling on XS. The native ModuleSource on XS performs considerably better than Babel on Node.js.
Documentation Considerations
None yet.
Testing Considerations
This change does not yet run these test suites under CI. Further work is needed to bring a specific verison of xst into CI and help developers reproduce that xst version as a local dependency. That may entail a submodule like Agoric SDK.
Compatibility Considerations
This change seeks to adapt the native XS Compartment to the API of the SES emulation in order to preserve broad compatibility. The author leaves evolution of the SES Compartment API to better resemble the native XS Compartment as a future exercise.
Refs: #400
Description
This introduces an XS-specific variant on the SES and StaticModuleRecord packages and includes a suite of parity tests for ensuring equivalent behaviors between Node.js and XS.
The compatible flavor of XS is very specific. Endo’s Compartment Mapper provides a Rollup-analogue bundler that respects Node.js’s conditional imports and generates a single script we can run under
xstand could use to bootstrapxsnap. To use these XS contingent variants on SES and StaticModuleRecord, we must use Endo’s bundler with the"xs"tag.Security Considerations
We must take care to ensure that our parity tests cover (or at the very least spot-check) all the security properties of SES.
Scaling Considerations
We expect considerable performance improvement using XS-specific SES shim and ModuleSource variants on XS and other improvements to ecosystem health in general, discussed in #400.
Using an XS-specific variant of SES and StaticModuleRecord makes it possible to even contemplate bundling on XS. The native ModuleSource on XS performs considerably better than Babel on Node.js.
Documentation Considerations
None yet.
Testing Considerations
This change does not yet run these test suites under CI. Further work is needed to bring a specific verison of
xstinto CI and help developers reproduce thatxstversion as a local dependency. That may entail a submodule like Agoric SDK.Compatibility Considerations
This change seeks to adapt the native XS Compartment to the API of the SES emulation in order to preserve broad compatibility. The author leaves evolution of the SES Compartment API to better resemble the native XS Compartment as a future exercise.
Upgrade Considerations
None yet.