Re: Shimmed ES(x) Modules

#1

Recent discussions have led us to consider the idea of shimmed ES modules as an alternative to the more traditional bundling-by-rewire. I started to document the work in more detail and will try to update this thread as I make progress.

Brief

Previous experimental work to look into the viability of retaining the semantics of a module’s top-level scope inside a nested scope (ie with (module.scope) { … }) lead to some exciting outcomes along with some unknowns worthy of further effort.

The unknowns that come to mind:

  1. Reliable and efficient way to tokenize at runtime (or if it is even needed).
  2. Throwing if an imported binding is being shadowed by a top-level declaration.
  3. Effective instrumentation of code and repair of scoped authorities (ie eval)
  4. Additional proxy work to retain scoping behaviours against realms.

The exciting outcomes that come to mind:

  1. Minimal rewrite is needed when demoting module code to scoped code.
  2. Minimal proxy hooks are required to affect scoping behaviours (ESM is always strict).
  3. Minimal shimming artifacts (obtrusion/restrictions limited to the single $h_exports or similar).
  4. Effective cross-compatibility and re/portability (ie unbundled or bundled with rollup).
#2
Documentation Updates
Features
  1. Export declarations — in progress
  2. Import declarations — pending
  3. Module evaluator — pending
  4. Module compiler — pending
Interfaces
  1. ShimmedModule interface — pending

  2. ShimmedModule.Exports Interface — in progress

  3. ShimmedModule.Imports Interface — new/pending

    Based on Apr18-2019 meeting discussions

  4. ShimmedModule.Scope interface — pending

  5. ShimmedModule.Namespace Interface — pending