Get web-features IDs from web-features, not Chromium source

[foolip]

Describe the bug chromestatus.com appears to get the list of web-features IDs from enums.xml in Chromium, which is the set of features that have use counters mapped, not all known features.

Screenshot showing some of the options:

To Reproduce Steps to reproduce the behavior:

1. Go to https://chromestatus.com/guide/new
2. Type 'color' or any part of a feature name in the Web Feature ID input
3. See that suggested names are "AccentColor" and similar.

Expected behavior We should use the feature IDs and names from the web-features package, ideally the auto-published "dev" package in https://www.npmjs.com/package/web-features?activeTab=versions since that would minimize the delay from landing a feature to showing it as an option on chromestatus.com.

If possible it would also be good to inline the feature descriptions to make it easier to figure out which feature is the right one.

Additional context This was uncovered by @chrishtr when working on print-color-adjust, as that doesn't show up as an option.

[foolip]

I think this help text also need to be updated:

Select the feature this belongs to in the web-features project: https://github.com/web-platform-dx/web-features. If your feature is not listed, pick "Missing feature".

It's not very easy to search for features in the GitHub repo. We could direct people to webstatus.dev instead, but really if all of web-features are inlined as options with name and description, then there should be no need to go somewhere else to find the feature ID. However, the help text could include a generated link to webstatus.dev once an ID has been picked.

[jrobbins]

@jstenback had asked us to use the usecounters, but we discussed it with Kadir and will switch to web-features.

[foolip]

@jrobbins there's a related issue which I just discussed with @atopal, which is what happens when there isn't a web-features ID yet. When that happens, the ideal would be that you get to propose a feature ID, and that files a web-features GitHub issue and shows that link to the user, so they can weigh in on the issue. Does that make sense and can we consider it part of this issue?

[jstenback]

@jstenback had asked us to use the usecounters, but we discussed it with Kadir and will switch to web-features.

Yep, at the time it seemed like the right thing to do as in my prediction at the time we'd have more cases where an engineer had created a draft feature in Chromium and wanted to link that to the Chromestatus entry than we'd have cases where the feature definition already existed. Now that the landscape is evolving to have earlier engagement with the WebDX community as a feature comes to life, switching to web-features makes more sense.

[chrishtr]

QQ: in the current setup, how long does it take after landing a CL like this for chromestatus to reflect that feature in the feature drop-down?

[jrobbins]

@chrishtr ChromeStatus parses https://chromium.googlesource.com/chromium/src/+/main/tools/metrics/histograms/metadata/blink/enums.xml once a day at 9pm PST. So in this case, I believe PrintColorAdjust started showing up in the ChromeStatus drop-down about 17 hours after that CL landed. I could make ChromeStatus run that job multiple times per day if needed.

[chrishtr]

I still don't see PrintColorAdjust in the dropdown here:

https://chromestatus.com/guide/editall/5159639697850368

Any idea why?

[jrobbins]

I chatted with Chris. The problem is that it is hard to spot new items in the list because the list is not alphabetical. It gives the impression of being alphabetical because the initial items are mostly alphabetical, but that's just the way that they were added to our database. I will add code to sort the list.