Automatic generation polyfills and tests based on spec

💡 Ideas
1

All new proposals required polyfills both before and after standardization (to smooth out the inertia of implementation in browsers). For this, there are currently a number of libraries that do this manually provide this, such as core-js, which is mainly used in Babel. But also other build tool chains & transpilers which not based on JavaScript like esbuild (Go) or SWC (Rust) also require such polyfills.

Generating code from a formal specification is quite a popular thing. Basically there is already a ready infrastructure for it (GitHub - es-meta/esmeta: ECMAScript Specification (ECMA-262) Metalanguage), which allows us to analyze, verify and build IR and AST from ts39 specs.

If we can automate this, we can automatically create polyfills for all popular instruments at once. And btw will guarantee consistency, mistake resistance and save time in the future.

1 Like
2

This is a cool idea though I think it may not work for some proposals when the change in the language is not something that can be done in existing JavaScript. For example it adds a fundamentally new feature (GitHub - tc39/proposal-weakrefs: WeakRefs) or new syntax (GitHub - tc39/proposal-optional-chaining).

Tools like es-meta emulate the entire language so that could be used to create a 'playground' where the proposal would work. But being able to generate a JS library that can be imported into an existing standard JS engine would be limited to proposals that can be polyfilled (new APIs).

3

Of course, not all proposals can be polyfilled, and not all need it, so to have an allowlist or blocklist is required.

4

It's particularly challenging because lots of the machinery of the spec can't be faithfully represented in JS in an ergonomic way. I use https://npmjs.com/es-abstract, a JS implementation of ES abstract operations, as the core of all of my polyfills ( https://npmjs.com/~es-shims ), and there are not-infrequent times when i have to write code differently for performance, ergonomics, or because the spec mechanics simply can't be done inside the engine (without being an engine itself, a la engine262).

There's certainly opportunity around automatically verifying implementations, and partially generating implementations - especially with a core like es-abstract already in existence - and I'd welcome explorations of that.

5

This https://dl.acm.org/doi/10.1145/3540250.3549097 work, to which es-meta/esmeta refers, talks about fully automatic JavaScript verification based only on the specification. In addition, the project fully implements the interpreter of the specification language itself. If this is the case according to 2d Futamura Projection, we can implement a compiler / translator.

JS implementation of ES abstract operations

This is true, but the specification is still written for a more concrete abstract machine (which differentiates types such as Smi, Number, Undefined). The JavaScript VM itself is already quite abstract. This is why, for example, TypeScript or esbuild polyfills are quite minimalistic. I am sure there is room for optimization and simplification

I didn't know about es-abstract - npm. Thanks!