Display APIs compatibility across different JavaScript runtimes. The data is automatically generated, based on MDN browser-compat-data format using the runtime tests from mdn-bcd-collector. Runtimes are displayed with their WinterCG Runtime Key.
The generated data is available in the packages/runtime-compat-data directory. It is published to npm as runtime-compat-data.
The list of APIs is generated by the browser-compat-data project. The features that we include can be found in the api and javascript/builtins directories. The tests are provided by the mdn-bcd-collector project. These are a mixture of automatically-generated tests for globals and properties, and manually-written tests for individual options. You can find the current tests in the data directory. This file is automatically generated from the mdn-bcd-collector repo.
These tests are designed to be run in a browser environment, so we use a slightly modified version of the test harness to allow them to run in the runtimes we support. The code for testing each of the runtimes is found in the src/runtimes directory. It is slightly different for each runtime, depending on how each is designed to be used. Some (such as Bun, Deno and Node) can run the test file directly from the CLI, while others expect to be run via a server. For these we use the project's own development server, and then use start-server-and-test to run the server and make a request for a function that runs the test file. The output of each of these is a data.json file in the runtime directory, which contains the results of the tests. If you want to check why a specific test failed, you should start by inspecting the contents of this file as it contains the code and error message for each test.
Another script then processes these files, combines them with the metadata from the browser-compat-data project, and then writes the data as a JSON file to the packages/runtime-compat-data directory. This is then published to npm.
The tests can be run locally, but the actual data generation process is run nightly on GitHib Actions, which opens a PR if there are any changes.
- Clone this repository
- Install latest LTS version of Node.js
- Install Bun
- Install Fastly CLI
- Install Wasmer
- Enable Corepack using
corepack enable - Install dependencies using
pnpm install - Generate the data using
pnpm run generate
If you want to run the tests for an individual runtime, run pnpm start in the src/runtimes/<runtime> directory.
The tests are only run against the latest stable version of each runtime, so the data only shows whether the feature is supported now. This is because the goal of the project is to track the current state, and not to track historical support. In most cases these runtimes are updated regularly, so this should not be a problem. The exception is Node.js, which is often run using old versions. For this you may like to compare the data with the MDN docs, which include support details for old versions of Node.
The actual tests are designed to run in browsers, so there may be inconsistencies. For the same reason, they also do not test for any WinterCG-specific features.
Several supported runtimes are normally used via a hosted service. These are tested locally using a development library or server, which may differ from the production environment.
Some runtimes may define a particular API object or method, but as a stub or noop rather than as an actual feature. In most cases this will be shown as being supported. Usually these feature make no sense outside a browser environment, but have been implemented to allow code to run cross-platform.
Deno is tested using the deno CLI, which has different support than the Deno Deploy service which has more limitations and often has features added on a adifferent schedule.
Tests are run against the open source Edge Runtime library (identified with the key edge-light) which run in Node. This is designed to be identical to the Vercel Edge Runtime (which is based on workerd), but there may be differences.
Tests are run using the Netlify CLI, which uses Deno. While this does use settings designed to mimic the production version, there may be differences.