[Tracking] WinterTC (TC55) Minimum Common Web API: gap analysis for boa_runtime

[KaustubhOG]

Overview

WinterTC (TC55) is an Ecma International Technical Committee working on a "Minimum Common Web API" standard — a baseline set of Web Platform APIs that all server-side JS runtimes (Deno, Bun, Cloudflare Workers, etc.) should implement for interoperability.

The TC55 spec (December 2025) defines the APIs that a conforming runtime must expose. This issue tracks the gap between what boa_runtime currently implements and what TC55 requires.

Implemented in boa_runtime

• console (optional extension)
• fetch / Headers / Request / Response (feature-gated, requires custom Fetcher impl)
• TextEncoder / TextDecoder (registered by default)
• setTimeout / setInterval / clearTimeout / clearInterval (registered by default)
• structuredClone (registered by default)
• queueMicrotask (registered by default)
• URL (feature-gated — searchParams / createObjectURL / revokeObjectURL unimplemented)
• postMessage (optional extension, requires custom MessageSender impl)
• AbortController / AbortSignal
• atob() / btoa()

Missing TC55 APIs

DOM

• Event / EventTarget

HTML

• CustomEvent / ErrorEvent / PromiseRejectionEvent
• MessageChannel / MessagePort / MessageEvent
• reportError()
• navigator.userAgent
• onerror / onunhandledrejection / onrejectionhandled
• self

URL

• URLSearchParams
• URLPattern

File API

• Blob / File

XHR

• FormData

Encoding

• TextDecoderStream / TextEncoderStream

Compression

• CompressionStream / DecompressionStream

Streams

• ReadableStream + ReadableStreamDefaultController + ReadableStreamDefaultReader
• ReadableByteStreamController / ReadableStreamBYOBReader / ReadableStreamBYOBRequest
• WritableStream + WritableStreamDefaultController + WritableStreamDefaultWriter
• TransformStream + TransformStreamDefaultController
• ByteLengthQueuingStrategy / CountQueuingStrategy

Web Crypto

• Crypto / SubtleCrypto / CryptoKey
• globalThis.crypto

Performance

• Performance / globalThis.performance

WebIDL

• DOMException

WebAssembly

• WebAssembly.* interfaces and methods

Notes

• Event / EventTarget should be implemented first — AbortController, MessageChannel, streams and others all depend on it
• AbortSignal currently has a simplified event listener implementation without a full EventTarget — implementing Event/EventTarget will make it fully spec-compliant
• WebAssembly likely requires separate discussion given its integration complexity( not finalised)

Ref: https://min-common-api.proposal.wintertc.org/

[KaustubhOG]

Hey @hansl following up on our Matrix conversation. I went through thel TC55 spec manually and cross-referenced it against the boa_runtime source to put together the gap analysis above.

Based on the direction you outlined, here's my understanding of the full plan:

• Create a new boa_tc55 crate containing only TC55-mandated APIs
• Migrate existing TC55-compliant APIs from boa_runtime → boa_tc55
• Implement the missing TC55 APIs in boa_tc55
• boa_runtime re-exports boa_tc55 and keeps non-TC55 extras (like fs)
• Future: move boa_tc55 to its own repo under boa-dev at Boa 1.0

A few things I noticed while auditing the source:

• URL.searchParams / createObjectURL / revokeObjectURL are currently stubbed and throw "not implemented"
• Event/EventTarget should likely come first since AbortController, MessageChannel, and the entire Streams API alll depend on it
• WebAssembly.* probably wants a separate discussion (maybe i deducted because it looks more complex for now )

Note: I verified everything manually against the source, but if anything in the gap list looks off — either already implemented or something miscategorized will be update the issue anytime.

Looking forward to your thoughts on the plan and next steps

Hi @KaustubhOG! I've been following the TC55 gap analysis. I'd like to help by implementing URLSearchParams . Since it's currently listed as missing/stubbed, I'll start working on a PR for it in the coming days. Let me know if there's any specific architectural preference for where this should live!

[KaustubhOG]

Hey @Tanush576, thanks for the interest in helping with this!

Right now I'm working on the initial architectural setup for this effort (specifically around introducing the boa_tc55 crate and defining how the APIs will be structured and registered). Since several of the APIs listed here depend on shared infrastructure and crate structure, I'm first discussing and finalizing that design i am currently working on it .

I'm also implementing parts of this issue in parallel, so starting individual APIs right now might lead to duplication or mismatches with the planned architecture.

Once the crate structure and architecture are finalized, I'll break the remaining work into smaller issues

In the meantime, feel free to contribute to other open issues — there are quite a few good ones in the repo listed .

Thanks for the heads-up, @KaustubhOG! That makes total sense—I'll wait for the boa_tc55 architecture and crate structure to land before diving into specific APIs to avoid any double work. In the meantime, I'll look into some of the other open issues or help review incoming PRs. Looking forward to the breakdown once the foundation is ready!

[KaustubhOG]

Progress Update

Phase 1 and Phase 2 are complete via #5105 (merged).
The boa_wintertc crate is now established with all 10 module stubs, and the architecture has been validated.

---

Current Status

• Phase 1 → boa_wintertc crate created
• Phase 2 → Architecture finalised
• Phase 3 → Migration from boa_runtime
• Phase 4 → New API implementations

---

Phase 3 Plan Migration (No Regressions)

Migrate modules from boa_runtime into corresponding boa_wintertc stubs as-is:

console    → boa_wintertc::console
interval   → boa_wintertc::timers     (renamed)
microtask  → boa_wintertc::microtask
clone      → boa_wintertc::clone
base64     → boa_wintertc::base64
abort      → boa_wintertc::abort
fetch      → boa_wintertc::fetch
text       → boa_wintertc::encoding   (renamed)

Implementation Approach

Each module will be migrated in order of complexity:

1. base64, clone, microtask (self-contained, no internal dependencies)
2. console, timers, abort ( minor wiring adjustments )
3. encoding (rename from text to align with TC55 naming )
4. fetch (last, complex, has sub-files (headers.rs, request.rs, response.rs)

For each module:

• Copy source files into the corresponding boa_wintertc stub
• Update internal use paths
• Add any missing dependencies to boa_wintertc's Cargo.toml
• Verify all existing tests pass

---

Notes

• This is a location change the same code moves from boa_runtime to boa_wintertc, no logic changes
• All existing tests will be preserved and must pass after migration
• No TC55 compliance fixes during this phase ,compliance gaps are left for Phase 4

---

cc @jedel1043

• Does the implementation approach looks fine ?
• Once migration is done, should boa_runtime immediately re-export from boa_wintertc, or should the two crates temporarily coexist until Phase 4 is complete?

[KaustubhOG]

Quick update: migration is in progress and depends on the shared infrastructure I am currently building out, so the modules land together rather than independently.

A first PR is already in progress (#5418) (how the rest proceed depends on how this first PR merges and the maintainers' view on it).

I will post a migration progress update in the next 2-3 weeks.