-
Notifications
You must be signed in to change notification settings - Fork 205
Add script to find unknown web-features IDs for triage #3051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Can't test this now because NPM is having issues: https://status.npmjs.org/ |
ef1d1b6 to
147d33f
Compare
|
It works now, with this output: Chromestatus entries
Source: chromestatus.com Chromium use counters
Source: webdx_feature.mojom web-platform-tests
Source: WEB_FEATURES_MANIFEST.json |
| return { | ||
| heading: "web-platform-tests", | ||
| items, | ||
| trailer: `Source: [WEB_FEATURES_MANIFEST.json](${asset.browser_download_url})`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This link isn't especially useful, but linking directly to the WEB_FEATURES.yml file that has the reference would require fetching and parsing all of them, which I don't want to do.
| const text = await chromiumSourceFile( | ||
| "tools/metrics/histograms/metadata/blink/enums.xml", | ||
| ); | ||
| const $ = cheerio.load(text); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works but I don't love it. It doesn't actually parse as XML it seems, the resulting tree has all of the <int> elements nested in another and it only works because I made the next line work regardless of tree shape.
Parsing webdx_feature.mojom directly is an option, but any difference in parsing from the Python code that parses it in Chromium would be a risk.
This feature was removed in web-platform-dx/web-features#1500. Discovered by auditing all features in WPT and elsewhere: web-platform-dx/web-features#3051
ddbeck
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to give this a try. I'm not quite sure what the resolution will be for all items, so I expect I'll be @-ing you for the first few attempts. 😄
Please resolve the conflicts and my comments, and merge at your leisure.
scripts/audit-consumers.ts
Outdated
| // deduplicated by ID. | ||
| async function* chromeStatusFeatures() { | ||
| const num = 500; | ||
| for (let start = 0 /* nothing here */; ; start += num) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| for (let start = 0 /* nothing here */; ; start += num) { | |
| for (let start = 0; /* nothing here */ ; start += num) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out that Prettier required this style. I'll remove the comment, the result is OK enough to not try to work around.
475846c to
48cb77b
Compare
web-features IDs are used by other projects, and there's no linting in place to guarantee that only valid IDs are used. Invalid IDs can appear becaues of typos, changes to web-features, or because an ID is used speculatively with the expectation it will be added to web-features. By reporting on the use of unknown IDs, we can catch these problems. If it becomes too common we might consider some form of linting in the monitored projects, but for now this is a lightweight approach that allows for maximum flexibility early in the lifecycle of a feature.
|
https://github.com/web-platform-dx/web-features/actions/runs/15975169650 is the first manual run of this. The output is still the same as in #3051 (comment). Next step would be to automatically file or update an issue once in a while. |
|
I used the output to burn down a few problems, and now this is the output: Chromestatus entriesNothing to see here! Chromium use counters
web-platform-tests
|
This feature was removed in web-platform-dx/web-features#1500. Discovered by auditing all features in WPT and elsewhere: web-platform-dx/web-features#3051
…feature, a=testonly Automatic update from web-platform-tests Remove web-features mapping for removed feature (#53133) This feature was removed in web-platform-dx/web-features#1500. Discovered by auditing all features in WPT and elsewhere: web-platform-dx/web-features#3051 -- wpt-commits: a24bf87a2cddf65fbe96ee41d5a9b06edbf16d09 wpt-pr: 53133
…feature, a=testonly Automatic update from web-platform-tests Remove web-features mapping for removed feature (#53133) This feature was removed in web-platform-dx/web-features#1500. Discovered by auditing all features in WPT and elsewhere: web-platform-dx/web-features#3051 -- wpt-commits: a24bf87a2cddf65fbe96ee41d5a9b06edbf16d09 wpt-pr: 53133
…feature, a=testonly Automatic update from web-platform-tests Remove web-features mapping for removed feature (#53133) This feature was removed in web-platform-dx/web-features#1500. Discovered by auditing all features in WPT and elsewhere: web-platform-dx/web-features#3051 -- wpt-commits: a24bf87a2cddf65fbe96ee41d5a9b06edbf16d09 wpt-pr: 53133
web-features IDs are used by other projects, and there's no linting in
place to guarantee that only valid IDs are used. Invalid IDs can appear
becaues of typos, changes to web-features, or because an ID is used
speculatively with the expectation it will be added to web-features.
By reporting on the use of unknown IDs, we can catch these problems. If
it becomes too common we might consider some form of linting in the
monitored projects, but for now this is a lightweight approach that
allows for maximum flexibility early in the lifecycle of a feature.