Runtime keys

Introduction

This Technical Report defines a canonical source for identifiers of unique ECMAScript runtime environments, known as runtime keys.

1 Scope

Runtime keys provide a consistent and predictable mechanism for identifying ECMAScript runtimes in a variety of contexts, including but not limited to project configuration files, package manifests, conditional exports, and runtime detection mechanisms. This document focuses on providing informative identifiers primarily for web servers, though other ECMAScript server environments may find it useful. These keys are not intended to be used in web browsers, which should be referenced by other mechanisms such as the browserslist project.

This Report defines:

the canonical source of runtime keys and associated metadata,
guidance for future ECMAScript runtimes to submit runtime keys, and
TC55's governance process for adding and modifying runtime keys to the Report.

Note 1

This Report does not define how runtime keys should be used by tools or libraries. The purpose of this Report is to prevent conflicts and provide a reliable, authoritative source of runtime identifiers.

Note 2

Inclusion in this Report does not imply that the specified runtime is fully conformant with any Ecma specification, including the WinterTC Minimum Common API. Inclusion does not imply endorsement of any kind.

2 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

2.1 ECMAScript runtime

implementation of the ECMA-262 ECMAScript language specification

2.2 runtime key

unique string identifier that represents a specific ECMAScript runtime environment

3 Runtime key structure

3.1 Key format

A runtime key satisfies all the following:

It is a string value.
It is usable in common configuration formats such as JSON and YAML.
It meaningfully represents the associated runtime environment.
It is simple and unambiguous.

Note

Future versions of this Report may define a formal grammar for allowable characters in runtime keys.

3.2 Key uniqueness

A runtime key included in this Report will not conflict with the following:

any other existing runtime key in this Report, or
any existing Browserslist browser entries. Note
This explicitly excludes references to server runtimes within Browserslist.

3.3 Key naming guidelines

Runtime keys are subject to expert review by TC55. Acceptable keys will:

avoid being too similar to existing keys,
avoid similarity to common English words or offensive terms,
avoid being too generic or similar to general terminology such as "Web Runtimes", "Edge Runtimes", or "JavaScript Runtimes", and
demonstrate reasonable specificity and clarity.

3.4 Runtime existence validation

The runtime environment represented by a key must actually exist, whether as open source, source-available, or proprietary software. Entries in this Report exist to identify real runtimes, not to reserve names for future projects.

Note

A runtime should demonstrate "proof of use" before being added to the Report. Examples include usage in package.json exports fields, published documentation, or active community adoption.

3.5 Runtime metadata

Each runtime key entry includes the following metadata:

Organization (required): The organization or individual responsible for the runtime
Name (required): The human-readable name of the runtime
Key (required): The unique string identifier
Description (required): A brief description of the runtime
Website (optional): The primary website for the runtime
Repository (optional): The source code repository URL, if available
Deprecated (required): A boolean indicating whether the key is deprecated

4 Canonical source for runtime keys

The following table lists runtime keys submitted to TC55 and reviewed by the Committee, sorted alphabetically by organization.

Note

This section is generated from the machine-readable source data (see A).

Table 1: Registered Runtime Keys

Key	Organization / Name	Description, Website, Repository
`andromeda`	Andromeda / Andromeda	A modern, and secure JavaScript & TypeScript runtime built in Rust, powered by the Nova engine and Oxc. Provides zero-config TypeScript, rich Web APIs (Canvas, Web Crypto, Storage, HTTP, SQLite), and aims for WinterTC compliance. Website Repository
`arvancloud`	Arvancloud / Edge Computing	The JavaScript runtime that powers Arvancloud Edge Computing. Website
`azion`	Azion / Edge Functions	Azion Edge Functions for ultra-low latency, edge-native applications, built with open standards for secure, high-performance serverless computing. Website
`bun`	Oven / Bun	Incredibly fast JavaScript runtime, bundler, transpiler and package manager - all in one. Website Repository
`convex`	Convex / Convex Runtime	The JavaScript runtime used to execute deterministic Query and Mutation Functions as well as nondeterministic Action Functions in the Convex backend platform. Website Repository
`deno`	Deno Land / Deno	A modern runtime for JavaScript and TypeScript. Website Repository
`edge-light`	Vercel / Edge Light	Developing, testing, and defining the runtime Web APIs for Edge infrastructure. Website Repository
`edge-routine`	Alibaba Cloud / edge-routine	The JavaScript/Webassembly runtime that powers Alibaba Cloud edge-routine. Website
`electron`	OpenJS Foundation / Electron	Build cross-platform desktop apps with JavaScript, HTML, and CSS. Website Repository
`fastly`	Fastly / JavaScript on Compute@Edge	JavaScript runtime for Fastly Compute@Edge. Website Repository
`kiesel`	Kiesel / Kiesel	A JavaScript engine and runtime written in Zig. Website Repository
`lagon`	Lagon / Lagon Runtime	Lagon is an open-source runtime and platform that allows developers to run TypeScript and JavaScript Functions at the Edge. Website Repository
`moddable`	Moddable / Moddable SDK	Open source runtime for resource-constrained embedded devices using standard JavaScript and TypeScript. Supports standard ECMA-419 APIs. Website Repository
`netlify`	Netlify / Edge Functions	Edge Functions connect the Netlify platform and workflow with an open runtime standard at the network edge. Website Repository
`node`	OpenJS Foundation / Node.js	Node.js is an open-source, cross-platform JavaScript runtime environment. Website Repository
`quickjs`	Fabrice Bellard / QuickJS	QuickJS is a small and embeddable Javascript engine. Website Repository
`quickjs-ng`	QuickJS-NG / QuickJS-NG	A fork of the original QuickJS project by Fabrice Bellard and Charlie Gordon. Website Repository
`pythonmonkey`	Distributive / PythonMonkey	Mozilla JS engine embedded into a Python host environment with cross-platform datatypes and event loop. Website Repository
`react-native`	Meta / React Native	A framework for building native apps using React. This key represents supported React Native JS runtimes on native platforms (excludes react-native-web). Website Repository
`react-server`	React / Server Components	Used by React Server Components. Website Repository
`rhino`	Mozilla / Rhino	Rhino is an open-source implementation of JavaScript written entirely in Java. Website Repository
`wasmer`	Wasmer / Wasmer Edge	The JavaScript runtime that brings JavaScript to Wasmer Edge. Website Repository
`workerd`	Cloudflare / workerd	The JavaScript / WebAssembly runtime that powers Cloudflare Workers. Website Repository

5 Governance and modification process

5.1 Proposing new runtime key entries

All ECMAScript runtimes are welcome to propose a key for inclusion in this Report, subject to the structure as described in 3. Runtimes which contribute to this Report are encouraged, but not required, to participate in Ecma TC55.

5.1.1 Proposal process

The proposer creates a pull request in the WinterTC55/runtime-keys GitHub repository.
The pull request adds the runtime entry to the machine-readable source data file (runtime-keys.json).
The entry includes all mandatory metadata fields as described in 3.5.
The entry is inserted in alphabetical order by key.
The pull request is reviewed by TC55 participants.
At least two delegates within TC55 not directly affiliated with the proposed runtime approve the pull request.
The pull request is formally approved at a TC55 plenary meeting before merging.
After plenary approval, designated editors merge the pull request and update the current draft Report.

5.1.2 Expert review

All proposed entries undergo expert review to ensure compliance with the naming guidelines specified in 3.3 and other expectations. Reviewers evaluate whether:

the proposed key is appropriately specific and non-generic,
the runtime has demonstrated proof of use or adoption,
the key does not conflict with existing entries or Browserslist identifiers, and
the metadata is complete and accurate.

TC55 may reject a runtime key submission for any reason, including those not enumerated in the above sections. In such a scenario, the Committee will provide that reason and information on how to resolve any issue.

5.2 Modifying entries

5.2.1 Metadata modification

Modifications to runtime metadata (organization, name, description, website, or repository) follow the same process as adding entries:

The proposer creates a pull request modifying the entry in runtime-keys.json.
The proposal continues as described starting at step 5 in the approval process.

5.2.2 Key immutability

To prevent breaking existing tools and configurations that depend on runtime keys, runtime keys are immutable and will not be modified except in extraordinary circumstances requiring plenary consensus.

5.2.3 Deprecation

Runtime keys may be deprecated to indicate that a runtime project is inactive or discontinued. To deprecate a key:

The proposer creates a pull request setting the deprecated field to true in runtime-keys.json.
The proposal continues as described starting at step 5 in the approval process.

Deprecated keys may be undeprecated if the original runtime project resumes activity, following the same approval process. Implementations should not add support for deprecated keys.

Note

Deprecated keys remain in the Report to preserve historical information and prevent reuse that could cause confusion.

5.3 Publication cadence

This Report is published on a semi-annual basis as an ECMA Technical Report at https://runtime-keys.proposal.wintertc.org/. Changes approved at TC55 plenary meetings between publication cycles can be found in the publicly-available draft maintained in the WinterTC runtime-keys repository.

Annex A (normative) Machine-readable canonical source

The authoritative, machine-readable form of the runtime key source is maintained as a JSON file: runtime-keys.json.

A.1 JSON schema

The runtime keys source data JSON file conforms to the following structure:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Runtime Keys",
  "description": "A collection of runtime keys for ECMAScript runtime environments",
  "version": "1.0.0",
  "lastModified": "YYYY-MM-DD",
  "runtimes": [
    {
      "organization": "string (required)",
      "name": "string (required)",
      "key": "string (required)",
      "description": "string (required)",
      "website": "string | null (optional)",
      "repository": "string | null (optional)",
      "deprecated": "boolean (required, default: false)"
    }
  ]
}

A.2 Accessing the source data

The current machine-readable source is available at:

Draft version: https://github.com/WinterTC55/runtime-keys/blob/main/runtime-keys.json
Published version: To be determined upon Ecma TR publication

Annex B (informative) Example usage

This Annex provides informative examples of how runtime keys may be used in practice.

Note

This specification does not prescribe how runtime keys should be used. The following examples are illustrative only.

B.1 package.json example

A library package might use runtime keys in its package.json to specify conditional exports and runtime version requirements:

{
  "name": "example-library",
  "version": "1.0.0",
  "exports": {
    "node": "./dist/node/index.js",
    "deno": "./dist/deno/index.js",
    "bun": "./dist/bun/index.js",
    "workerd": "./dist/workerd/index.js"
  },
  "engines": {
    "node": ">=18",
    "deno": ">=1.30",
    "bun": ">=1.0"
  }
}

B.2 Configuration File Example

A build tool or framework might use runtime keys to specify runtime-specific configuration:

{
  "runtimes": {
    "node": {
      "outputDir": "./dist/node",
      "target": "ES2022"
    },
    "deno": {
      "outputDir": "./dist/deno",
      "target": "ES2022"
    },
    "workerd": {
      "outputDir": "./dist/workerd",
      "target": "ES2022",
      "polyfills": ["node:buffer"]
    }
  }
}

Bibliography

ECMA-262, ECMAScript® Language Specification
https://tc39.es/ecma262/multipage/

Copyright & Software License

Ecma International

Rue du Rhone 114

CH-1204 Geneva

Tel: +41 22 849 6000

Fax: +41 22 849 6001

Web: https://ecma-international.org/

Copyright Notice

ALTERNATIVE COPYRIGHT NOTICE AND COPYRIGHT LICENSE

By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.

Permission under Ecma’s copyright to copy, modify, prepare derivative works of, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:

(i) The full text of this COPYRIGHT NOTICE AND COPYRIGHT LICENSE in a location viewable to users of the redistributed or derivative work.

(ii) Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the Ecma alternative copyright notice should be included.

(iii) Notice of any changes or modifications, through a copyright statement on the document such as “This document includes material copied from or derived from Runtime keys https://github.com/WinterTC55/runtime-keys.
Copyright © Ecma International.”

Disclaimers

THIS WORK IS PROVIDED “AS IS,” AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.

Software License

All Software contained in this document ("Software") is protected by copyright and is being made available under the "BSD License", included below. This Software may be subject to third party rights (rights from parties other than Ecma International), including patent rights, and no licenses under such third party rights are granted under this license even if the third party concerned is a member of Ecma International. SEE THE ECMA CODE OF CONDUCT IN PATENT MATTERS AVAILABLE AT https://ecma-international.org/memento/codeofconduct.htm FOR INFORMATION REGARDING THE LICENSING OF PATENT CLAIMS THAT ARE REQUIRED TO IMPLEMENT ECMA INTERNATIONAL STANDARDS.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the authors nor Ecma International may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE ECMA INTERNATIONAL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ECMA INTERNATIONAL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.