Investigate @babel/standalone for ES2020+ syntax repair in Playground (Chakra runtime)

[bkaradzic-microsoft]

Background

Babylon Native's Chakra-based runtime parses only up to ES2019 syntax. Modern Babylon.js Playground snippets (sourced from the live Babylon playground server at runtime) routinely use:

• Optional chaining (?.)
• Nullish coalescing (??)
• Numeric separators (1_000_000)
• Logical assignment (||= &&= ??=)
• Private class fields (#field)

These snippets fail with SyntaxError at the eval() site in Apps/Playground/Scripts/validation_native.js, causing ~26 visual tests to be excluded from automatic testing on Chakra Playground builds.

Why this is hard

The transpilation has to run inside the JS host (Chakra) at parse-failure time, not at build time, because the snippet source is fetched dynamically from the Babylon playground server. So traditional Node.js-based tools (babel CLI, swc CLI) aren't directly usable.

A previous attempt (PR #1709, since closed) shipped a ~114-line regex-based syntax repair polyfill. It addressed the parse failures but introduced semantic divergence (?. rewritten to . loses null-short-circuit), and only unlocked 1 of 26 affected tests. The other 25 either hit runtime TypeErrors from the divergence (9), need ES2022 features the regex doesn't cover (4), or hit non-transpilation blockers like missing modules (12).

Options to investigate

	Approach	Tradeoff
A	Bundle @babel/standalone into Playground SCRIPTS, run inside Chakra	~1 MB extra JS shipped + parsed at startup; semantically correct; well-maintained
B	swc compiled to WebAssembly, run inside Chakra	Chakra does not support WASM in the BN-shipped version — likely not viable
C	Native binding to swc (Rust) via C++, expose to JS host	Adds native dependency + cross-platform binary build; significant infra
D	Build-time pre-transpile of cached snippets	Requires intercepting/caching Babylon CDN fetches; significant infra

Suggested deliverables for this investigation

1. Measure the actual cost of bundling @babel/standalone (size on disk, Chakra parse time at startup, memory footprint).
2. Prototype option A and confirm the ~14-test uplift estimate (the 9 ?. divergence + 4 ES2022 + some asset/url tests that may benefit from cleaner transformation).
3. Compare against options C / D for long-term sustainability.
4. Decision + RFC.

Out of scope

This issue is only about ES2020+ syntax repair in the Chakra Playground. The non-transpilation blockers (missing babylonjs-addons, missing earcut, asset/url errors) are tracked separately.