About the mdn-bcd-collector

This project's goal is to help keep MDN's browser-compat-data (BCD) as up-to-date and as accurate as possible, by running predefined JavaScript code in browsers to determine what features are and are not supported.

Feature detection tests are generated based on machine-readable data (Web IDL, CSS definitions, etc.) from web standards, with support for custom tests and custom data where needed. Tests are then run within browsers (either manually or via a Selenium WebDriver script), generating a results file that can either be downloaded locally or submitted to the mdn-bcd-results repository.

Project History

This project was started by Philip Jägenstedt at Google, who later contracted Vinyl Da.i'gyu-Kazotetsu to help develop the project further. Vinyl had since forked the project and had been maintaining her own version under her own company, Gooborg Studios. The project now lives under Open Web Docs ownership, with Gooborg Studios continuing to handle the hosting.

How to Use

The collector project has two main parts:

These parts work in tandem to ultimately help ensure that BCD is as accurate as possible. Depending on what your end goal is, you may use these components together, separately, or in other ways than outlined above.

General workflow

The workflow for the collector's process looks something like this:

flowchart TD
  subgraph collector_maintainer [mdn-bcd-collector maintainers:]
    release(A new version of the mdn-bcd-collector is released)
    selenium(A Selenium WebDriver script is triggered)
    selenium_run(The Selenium script tests all browsers in CTs released since 2020)
    manual(Browsers unavailable in CTs are tested manually)

    release --> selenium --> selenium_run --> browser
    release --> manual ---> browser

    subgraph browser [In the browser...]
      direction TB
      open(The collector's website is opened) -->
      run(The #quot;Run#quot; button is clicked to run all of the tests) -->
      export(Once tests are completed, they are exported)

    browser --> results(All of the results are collected and stored in the mdn-bcd-results repo)

  collector_maintainer --> bcd_maintainer

  subgraph bcd_maintainer [BCD maintainers:]
    pull(Pull the latest mdn-bcd-collector and mdn-bcd-results versions) --> update_bcd & add_new_bcd
    subgraph update_bcd [update-bcd]
      direction TB
      update_run(Run the update-bcd script to make local changes to BCD)
      update_pr_bcd(Submit pull requests to apply changes to BCD)
      update_pr_collector(Submit issues/pull requests to fix collector tests)

      update_run --> update_pr_bcd & update_pr_collector

    subgraph add_new_bcd [add-new-bcd]
      direction TB
      add_run(Run the add-new-bcd script to locally add new supported features to BCD) -->
      add_pr(Submit pull requests to apply changes to BCD)

(Thanks to BrowserStack, SauceLabs and LambdaTest for providing us with free CT resources!)

The Website

The "website" encompasses everything involved with the web interface. This includes:

The role of the website is to act as a backend during the results collection process, serving files and test code to the browser to determine what features are and are not supported in that browser. It then receives the results from the browser so that it may be compiled into a JSON results file and either downloaded or exported to GitHub in the mdn-bcd-results repository.

The update scripts

The update scripts take the results collected from the website, compiles them, and then makes changes to the files in BCD to synchronize them with the collector's results. For BCD contributors, this is the primary interaction they will have with the collector. There are two scripts involved in updating BCD:

See docs/update-bcd.md for information on how to use the update-bcd and add-new-bcd scripts.


Why not generate your own version of BCD using the collected results?

The collector was designed from the ground up to help with maintaining BCD. In no way was the collector designed to compete against BCD, and for various reasons, it may never be able to:

Why not use the example code from MDN?

The example code on MDN Web Docs are wonderful to demonstrate to web developers how to use a feature in their own projects. However, the examples on MDN pages are written with different goals in mind:

While some of our code is based on MDN Web Docs examples, it is modified to fit our needs better.

Why not use tests from WPT.live?

web-platform-tests (WPT) is a great resource to test support for various features. However, its purpose differs from ours:

While some of our code is based on WPT.live tests, it is modified to fit our needs better.

© 2023 Gooborg Studios + Open Web Docs + various contributors, © 2020-2022 Google LLC, Mozilla Corporation and Gooborg Studios.

This project is under the Apache License 2.0 license.