ESPACK v0.3.0 — manifest-assisted merge + shared-accel discovery
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.dlland 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