Repository files navigation

Display APIs compatibility across different JavaScript runtimes. The data is automatically generated using the runtime tests frommdn-bcd-collector and published in the MDNbrowser-compat-data format.

View the results orre-use the data.

The data is generated using the tests from themdn-bcd-collector project. These were originally created for MDN'sbrowser-compat-data, which is the data that powers sites such as theMDN Web Docs andCanIUse. These tests were designed to run in a browser environment, so we use a slightly modified version of the test harness to allow them to run in non-browser runtimes.

The runner code is is slightly different for each runtime, because of the variety of different ways they are designed to be invoked. Broadly they fall into two groups - the ones that can be run directly from the CLI, and others that are invoked via an HTTP request. For these we use the project's own development server, and then usestart-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 adata.json file in each runtime directory, containing 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 about each API from thebrowser-compat-data project, and then writes the data as a JSON file to theruntime-compat-data directory. This is then published to npm as theruntime-compat-data module.

The tests can be run locally, but the actual data generation process is run on GitHub Actions, which opens a PR if there are any changes.

• Clone this repository
• Install latest LTS version ofNode.js
• InstallBun
• InstallFastly CLI
• InstallWasmer
• DownloadLLRT and place executable inPATH
• EnableCorepack usingcorepack enable
• Install dependencies usingpnpm install

To generate data for all runtimes, runpnpm run generate in the project source.

To generate data for an individual runtime, navigate togenerator/runtimes/<runtime> and runpnpm start.

To view the website, runpnpm run website, then navigate tolocalhost:3000.

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.

The tests were created for browsers so they make some assumptions about their environment. We try to work around as many as we can, but there are still false negatives. For example, most of theRequest andURL tests assume that they can create relative URLs. These don't work in most non-browser runtimes by design, because there is nolocation.href for them to be relative to. Currently this means that a lot of these tests are reporting as failed, even though the runtimes support most of these features.

The tests are only run against the latest stable version of each runtime, so the data only shows whether the feature is supported now. 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 withthe MDN docs, which include support details for old versions of Node.

Deno is tested using thedeno CLI, which has different support than the Deno Deploy. That service has more limitations and often has features added on a a different schedule.

Tests are run against the open sourceEdge Runtime library (identified with the keyedge-light), which run in Node. This is designed to be identical to the Vercel Edge Runtime (which is based onworkerd), but there may be differences. This is particularly likely to be the case when a feature is reported as unsupported on Edge Runtime but supported by workerd.

Tests are run using the Netlify CLI, which uses the Deno CLI. While this does use settings designed to mimic the production version, there may be differences. We have manually skipped some of the features (such as WebGPU) that falsely reported as supported, there there may still be some false results.

Published under theMIT license.Made bycommunity 💛