Skip to content

jco leg is a toolchain generation behind the siblings (registry jco-transpile ^0.5.2, transpile-time --map wiring, floating shim pins) #345

Description

@lann

The conformance jco leg predates the websocket/webrtc pattern and has drifted from it on three axes (conformance/driver-ct/jco/):

  1. Transpiler: registry @bytecodealliance/jco-transpile: ^0.5.2, while websocket and webrtc pin the lann/jco fork release tarball (jco-transpile-0.6.2-fa6990d) that carries the p3/JSPI fixes the family keeps hitting (-I async: future.transfer trampoline const is emitted after the init generator that references it (TDZ ReferenceError at instantiation) lann/jco#34/dx: development-friction debt — shared core crate, generated jco flags, guest wrappers, harness cleanups #35 reproduce on 0.6.3 upstream too).
  2. Wiring style: all interface wiring happens at transpile time via a wall of --map flags in package.json scripts (SUT host, test-context, per-interface preview2-shim paths), vs the siblings' -I async instantiation + runtime bindImports — one transpile, imports bound at instantiate time. Two styles is one more thing to know per repo, and the --map copies are the least reviewable text in the tree.
  3. Pinning philosophy: ^0.5.2 / preview2-shim ^0.17.4 / playwright-core ^1.61.1 float on semver ranges in the same file whose component-test pin is rev-exact by policy.

Migrate to the sibling shape: fork tarball, -I async, runtime import binding (via the shared helpers once polymorph-components/polymorph-test#58 lands), exact pins. Risk is concentrated in the browser leg (worker pool + import-map plumbing) — gate on the full matrix including jco-browser, not just jco-node.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions