Runtime Keys

Draft Community Group Report,

This version:
http://runtime-keys.proposal.wintercg.org
Editor:
(Vercel)

Abstract

A proposal defining standard identifier keys for various runtime environments

Status of this document

This specification was published by the Web-interoperable Runtimes Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This proposal defines a list of keys that represent various runtime environments. These keys can be used in a variety of ways, and should be considered a reliable representation of the given runtime. For example, they may be used in a project configuration file to indicate the given project supports the specified runtime. This specification does not detail how the keys can be used; that is left up to community developed tools. The point of this proposal is too only define what the keys are in order to prevent conflicts and give users a reliable list of platforms they can build tooling around.

2. Keys

2.1. Cloudflare - workerd

The JavaScript / Wasm runtime that powers Cloudflare Workers.

Key: workerd

Website: https://workers.cloudflare.com/

Repository: https://github.com/cloudflare/workerd

2.2. Deno Land - Deno

A modern runtime for JavaScript and TypeScript.

Key: deno

Website: https://deno.com

Repository: https://github.com/denoland/deno

2.3. Meta - React Native

Create native apps for Android and iOS using React.

Key: react-native

Website: https://reactnative.dev/

Repository: https://github.com/facebook/react-native

2.4. Netlify - Edge Functions ## {#}

Edge Functions connect the Netlify platform and workflow with an open runtime standard at the network edge.

Key: TODO: <key>

Website: https://docs.netlify.com/edge-functions/overview/

Repository: https://github.com/netlify/edge-functions

2.5. OpenJS Foundation - Electron

Build cross-platform desktop apps with JavaScript, HTML, and CSS.

Key: electron

Website: https://www.electronjs.org/

Repository: https://github.com/electron/electron

2.6. OpenJS Foundation - Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment.

Key: node

Website: https://nodejs.org

Repository: https://github.com/nodejs/node

2.7. Oven - Bun

Incredibly fast JavaScript runtime, bundler, transpiler and package manager - all in one.

Key: bun

Website: https://bun.sh/

Repository: https://github.com/oven-sh/bun

2.8. Vercel - Edge Runtime

Developing, testing, and defining the runtime Web APIs for Edge infrastructure.

Key: edge

Website: https://edge-runtime.vercel.app/

Repository: https://github.com/vercel/edge-runtime

3. Key Management

3.1. Adding a key

All JavaScript runtimes are welcome to create a key and add it to this list. New keys must not conflict with another existing key. Runtime entries on this list are encouraged, but not required, to participate in the community group.

To propose a new key, create a pull request in runtime-keys repository that adds the desired key to the index.bs file using the following format:

## <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}

<Runtime Description>

Key: `<Runtime Key>`

Website: [<Runtime Website>](<Runtime Website>)

Repository: [<Runtime Repository>](<Runtime Repository>)

The key should be inserted in alphabetical order based on the first character of the Runtime Organization

Keys should meaningfully represent the relative runtime and be a simple, string-like value so it can be used in common configuration formats such as JSON and YAML.

Entry pull requests must be approved by at least two active members of the community group that are not directly affiliated with the proposed runtime.

3.2. Modifying a key

Modifying an entry requires opening a pull request and recieving two approvals from active community group members not affiliated with the relative runtime project.

Modifications can be made to aspects such as the Organization, Name, Description, Website, and Repository. Aside from extraordinary circumstances, to prevent breaking tools built around this list, Keys are not modifiable. Keys may be deprecated to indicate inactive runtime projects.

Deprecated Keys may be undeprecated and claimed by another runtime.

To deprecate or undeprecate a key, open a pull request adding or removing <b>[Deprecated]</b> from the Name:

+ ## <b>[Deprecated]</b> <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}
- ## <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119