Parent: #1
Goal
Before the public API stabilizes, remove or redesign compatibility-first surfaces that make zig-js harder to reason about, test, optimize, or secure. Backward compatibility is not a constraint yet; correctness, clarity, and long-term quality are.
Current status
The initial compatibility-shim audit has been largely implemented. The documented C API still uses JavaScriptCore-shaped names where useful for embedders, but the old dangerous pattern of silently ignoring compatibility parameters has been removed or converted into explicit fail-fast behavior.
Implemented cleanup includes:
JSEvaluateScripthonorsthisObject,sourceURL, andstartingLineNumberthrough source-aware syntax/runtime metadata.JSGlobalContextRetain/JSGlobalContextReleasemaintain a checked C-API refcount.JSObjectSetPropertyhonors property attributes.JSObjectMakeFunctionWithCallbackhonors function names and rejects null callbacks.- Non-null
JSClassRefinputs are rejected rather than silently ignored. - C-boundary hardening rejects or guards null handles, wrong-context handles, invalid UTF-8, overflowed refcounts/protection counts, malformed argv vectors, ambiguous result-wrapper allocation failures, host callback null returns, and foreign-thread
JSWorkerRefhandles. - C-created objects/arrays/functions use ordinary runtime prototypes and real runtime conversion/call/construct/property semantics rather than compatibility-shaped stubs.
- Docs describe zig-js semantics directly and call out zig-js extensions (
ZJSGlobalContextCreateThreaded,JSWorker*) instead of implying broad JavaScriptCore compatibility.
Remaining policy
- Keep taking breaking API changes before stabilization when they make the contract simpler, safer, or more internally coherent.
- Do not expose test-only controls such as
parallel_js,parallel_midscript_gc, or harness profile switches as stable embedder API. - If a future compatibility-shaped parameter is added, it must have real documented behavior, a focused test, or a documented fail-fast reason.
- Close this tracker after the latest full CI gate is green, or split any newly discovered API/security cleanup into narrower follow-up issues.
Acceptance criteria
- No stable API surface keeps an inert compatibility parameter unless there is a documented reason and a test for the promised behavior.
- Docs describe zig-js semantics directly rather than implying JavaScriptCore compatibility where it is incomplete.
- Any breaking rename/removal is done before stabilization and covered by focused compile/API tests.
- The C and Zig entry points remain easy for embedders to use without relying on undocumented harness controls.