Architecture

Overview

The general steps compat-db uses to generate compatibility records:

1. WebIDL for all web and ES APIs
   • Generate eslint plugin required info ast node types
   • Instance property/method or not
   • Static property/method or not
2. Generate compatibility tests
   • Tests will assert if the API is supported in the environment they run in
   • Test runner
3. Run the generated tests
   • “Binary search” algo
   • Save results to database
   • Publish compiled database to NPM
4. Use published database in eslint-plugin-compat
   • Use generated API information to apply lint rules
   • Use eslint plugin required info
   • ast node types
   • Instance property/method or not
   • Static property/method or not

Components Overview

1. Running $ npm run build-compat will run compat-tests/setup.js to create jobs. These jobs will determine the compatiblity of APIs in different browsers.

   • These jobs are created by calling src/providers/Providers.js

2. Providers.js runs MicrosoftApiCatalogProvider.js, allowing it to return records.

   • MicrosoftApiCatalogProvider.js collects data from MicrosoftApiCatalogData.js and returns an array of records. These records include information such as the names and prototype chains of each API.

   • Providers.js will returns these records

   • Providers.js is stateless and does not modify anything. Records aren't stored anywhere since Providers.js can be ran at anytime

   • RecordType: A type of record that should be returned from each provider

3. Jobs are added to a database that is hosted by the user

   • Database is created by running $ npm run migrate

-----BELOW THIS LINE NEEDS TO BE CLARIFIED-----

4. Use the records collected from step 1 and generate snippets of code to be run inside browsers. These generated tests will be ran against certain browsers in order to determine if an API is supported or not.

5. These tests will be run against certain versions of browsers. Webdriverio is the library that we use to send these tests to servers which run test tests against browsers. AssertionFormatter is responsible for the generation of these tests. The service that runs runs these tests on browsers is Saucelabs. The results of running these tests these tests will be stored to a temporary database after they have finished running on Saucelabs. See DatabaseType for more details of what the structure of the temporary database will look like.

6. Collect all the results from the database and format them into a usable manner. Split the temporary database into all.json (all the records of the temporary database), css.json (only the css records in the tmp database), and js.json (only the js records in the tmp database). These json files will be provided to the user along with an node API interface to them. Users can import whichever database they choose. Splitting the database into multiple json files allows faster traversal.

Architecture Diagram