There's no authoritative way to learn which V8 version a workerd release embeds, or which version production currently runs — yet that's exactly what determines the available JavaScript built-ins (it's the embedded V8 version, not compatibility_date, which only gates runtime API behavior). This was confirmed in #517:
"We shipped V8 11.0 in late February, so these should have landed then, and AFAICT they are indeed supported today." — @kentonv
Since the V8 version is the only thing that answers "is this built-in available?" and it's undocumented, choosing lib in tsconfig.json is guesswork:
"lib": ["esnext"] can type built-ins production V8 hasn't shipped → clean type-check, runtime TypeError.- A conservative
"lib": ["es2022"] silently hides features that are live.
workerd --version prints only a date (workerd 2026-05-07) — no V8 version, and prod may run a newer V8 than any local binary.
The only workaround is folklore — grep V8-bump mentions from scattered threads, or file a "does workerd have X?" issue and wait for a maintainer. Not discoverable, doesn't scale. Please surface the V8 version in a discoverable form such as workerd --version and in every GitHub Release / changelog entry, making the local runtime self-describing and giving a release→V8 history — and state the V8 production currently runs somewhere stable, since prod can lead any pinned local binary.
There's no authoritative way to learn which V8 version a workerd release embeds, or which version production currently runs — yet that's exactly what determines the available JavaScript built-ins (it's the embedded V8 version, not
compatibility_date, which only gates runtime API behavior). This was confirmed in #517:Since the V8 version is the only thing that answers "is this built-in available?" and it's undocumented, choosing
libintsconfig.jsonis guesswork:"lib": ["esnext"]can type built-ins production V8 hasn't shipped → clean type-check, runtimeTypeError."lib": ["es2022"]silently hides features that are live.workerd --versionprints only a date (workerd 2026-05-07) — no V8 version, and prod may run a newer V8 than any local binary.The only workaround is folklore — grep V8-bump mentions from scattered threads, or file a "does workerd have X?" issue and wait for a maintainer. Not discoverable, doesn't scale. Please surface the V8 version in a discoverable form such as
workerd --versionand in every GitHub Release / changelog entry, making the local runtime self-describing and giving a release→V8 history — and state the V8 production currently runs somewhere stable, since prod can lead any pinned local binary.