web-platform-dx / web-features

Exploring how to present Web platform features adoptability
https://web-platform-dx.github.io/web-features/
Apache License 2.0
364 stars 71 forks source link

Synchronize `compat_features` with mdn/browser-compat-data tags #1672

Open ddbeck opened 2 months ago

ddbeck commented 2 months ago

Goal

When we override compat_features in a YAML file here, those changes ought to propagate to mdn/browser-compat-data. Likewise, new features originating in mdn/browser-compat-data ought to bubble up to web-features.

Background

Open Web Docs is working on several tasks including:

Provide synchronization of browser-compat-data keys between the mdn/browser-compat-data and web-platform-dx/web-features repositories. Contribute source code required to synchronize keys to their respective repositories on GitHub.

(see https://github.com/openwebdocs/project/issues/208)

But we're not capturing this work here on the repo anywhere. This issue is attempting cover it.

ddbeck commented 2 months ago

There's two sides of this: upstreaming and downstreaming.

Downstreaming

Downstreaming is sending changes from the upstream side (mdn/browser-compat-data) to the downstream (web-platform-dx/web-features).

I'd expect a web-features workflow along these lines:

  1. Start by upgrading @mdn/browser-compat-data in web-features (e.g., via Dependabot, repository/workflow dispatch, or cron workflow).
  2. Run npm run bcd-sync (or similar). Do these steps:
    1. If there exists a tag in BCD that matches a compat_features list, then delete the compat_features list from the file and commit.
    2. If there exists a tag in BCD that differs from the compat_features list, then annotate the .yml file’s compat_features line with the discrepancy. Note: some discrepancies will be expected/desired (e.g., BCD is “stale”); this should not fail tests or block merging.
    3. Run npm run dist and commit.
    4. Push the changes.
  3. Review. If applicable, push corrective changes to the PR. Finally, approve the PR.
  4. Merge the PR.
  5. After merging, if there any web-features: keys that exist in BCD that do not have a corresponding feature ID, then generate an issue (or perhaps even a PR from a template) in web-features reporting a "missing" feature.

Upstreaming

Upstreaming is sending changes from the downstream side (web-platform-dx/web-features) to the upstream side (mdn/browser-compat-data).

I'd expect an mdn/browser-compat-data workflow:

  1. Start by upgrading web-features in a PR (e.g., via Dependabot, repository/workflow dispatch, or cron workflow).
  2. Run some script that does these steps:
    1. Compare the list of feature IDs in web-features with the list of tags in BCD.
    2. Produce a Checks report (e.g., some Markdown) that shows what tags/features will change.
    3. Run migrate-to-bcd.
    4. Push the results to the PR.
  3. Review and approve the PR.
  4. Merge the PR.