Skip to content

ESPACK v0.3.0 — manifest-assisted merge + shared-accel discovery

Choose a tag to compare

@thelabcorner thelabcorner released this 10 Aug 19:13
· 6 commits to master since this release

ESPACK v0.3.0

Four-layer merge architecture: one self-extracting loader per composed file, N payloads, one shared accelerator.

New in this release

  • --manifest-out (espack-build.mjs): explicit manifest sidecar (schema v1, fixed key order, payload-only — no machine paths). No-flag output is byte-identical to v0.2.0.
  • espack-merge.mjs (new CLI): merges N manifests into ONE bundle — collision policy: same name+version+same bytes dedupe; same name+version+different bytes hard error; same name+different version keeps the higher integer version; accelerator must match across manifests. Merged bundle name defaults to the first manifest (skip re-extraction).
  • Shared-accel discovery (loader): accel-less bundles now discover %LOCALAPPDATA%\espack\ESB64Native_v1.dll and decode payloads natively (3–10 µs vs ~35 ms JSX lane); embedded-accel extraction failure falls back to the on-disk shared accel. Fail-open, capability-checked.
  • Load-by-name contract: consumers load payloads by name (ESPAK.load('LibA')) — index-0 is not a stable API under merge.

Validation

  • Node: 33/33 espack + 6/6 merge + vendor-sync drift guard
  • Live on Illustrator 30.6.0 via COM: 71/71 e2e checks — multi-payload load-by-name (native, byte-exact), merged-bundle accel dedupe (one accel literal), cache migration (skip-extract + stale-old harmless), facade last-wins ordering

Assets

  • ESPAK-demo.accel.jsx — runnable standalone demo bundle (shared accelerator, #target illustrator)
  • ESB64Native.dll — the shared WHATWG-exact accelerator (9,728 B) embedded in every accel bundle