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.
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.
The collector project has two main parts:
update-bcd
updates BCD based on results collected from the websiteadd-new-bcd
adds data for new standard features that BCD does not yet track, also based on results collected from the websiteThese 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.
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) end browser --> results(All of the results are collected and stored in the mdn-bcd-results repo) end 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 theupdate-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 end subgraph add_new_bcd [add-new-bcd] direction TB add_run(Run theadd-new-bcd
script to locally add new supported features to BCD) --> add_pr(Submit pull requests to apply changes to BCD) end end
(Thanks to BrowserStack, SauceLabs and LambdaTest for providing us with free CT resources!)
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 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:
update-bcd
-- this updates the data for features tracked by BCDadd-new-bcd
-- this adds features that are not currently tracked by BCDSee docs/update-bcd.md for information on how to use the update-bcd
and add-new-bcd
scripts.
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:
@mdn/browser-compat-data
is widely used in many projects and has many contributors/reviewersThe 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:
let
/const
, arrow functions, etc.) for modern browsers is preferred in MDN examples, as web developers should utilize them; our tests are designed to run on as old of browsers as possibleWhile some of our code is based on MDN Web Docs examples, it is modified to fit our needs better.
web-platform-tests (WPT) is a great resource to test support for various features. However, its purpose differs from ours:
let
/const
, arrow functions, etc.) for modern browsers is preferred in WPT tests; our tests are designed to run on as old of browsers as possibleWhile 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.