Publish extended JSON in main web-features package

[ddbeck]

We should consider publishing the per-key compat statuses in the web-features package directly.

Increasingly, we've seen consumers skipping over the web-features extended JSON data in favor of compute-baseline, which is clunkier (and skips over any editorial overrides we might wish to apply), just to get at per-key statuses from BCD. Examples of this include the recent VS Code integration.

We ought to compare the size of the web-features package with and without the extended data, get feedback from existing consumers, and make a decision about whether to include it.

[captainbrosset]

Thanks for filing @ddbeck. I thought we already had an issue for this, but looks like no.
Should we ping consumers on this issue directly?
@rviscomi can probably share some perspective from the VS Code hover card side of things.

[ddbeck]

I was planning to talk to the MDN team and Alexis of caniuse about these directly (and report back here), since I already have standing meetings with them—though in both cases, I believe they're using the bare JSON release assets not the npm package.

Rick and I talked about this last week, which was part of the incitement for filing this issue, so I believe he's feeling positive toward the idea already (though I'd appreciate his explicit input here). We started to talk about a related idea, which would be convenience methods for looking up per-key statuses; I'll file another issue, if this one makes some progress.

And quickly here:

Artifact	Size (uncompressed)	Size (gzip)
data.json	1307 kB	220 kB
data.extended.json	4124 kB (+216%)	361 kB (+64%)

[rviscomi]

I fully support this plan. While it's technically possible to pull down the extended JSON, it'd be much more convenient for tooling consumers to access it via the web-features package. Even better if there was a helper function similar to getStatus from compute-baseline.

For reference, here's how ESLint CSS uses it: https://github.com/eslint/css/blob/a035fa7c5b36845b73131e2d1a0b8c83f6c89ffe/tools/generate-baseline.js#L12

VS Code is actually using the computeBaseline function: https://github.com/microsoft/vscode-custom-data/blob/d17efbb5d4da22adcdbf3316b2f0e91e2eac7325/web-data/css/generateData.mjs#L382-L390

Having a single canonical function in web-features would help simplify the integration for tooling consumers.

[ddbeck]

I was planning to talk to the MDN team and Alexis of caniuse about these directly (and report back here), since I already have standing meetings with them—though in both cases, I believe they're using the bare JSON release assets not the npm package.

I confirmed with MDN that they're not using the npm package anyway (and they're already using the extended JSON artifact). It'll be a few weeks before I can talk to Alexis, but I'm more confident about caniuse than than I am the MDN side of things, so this is probably safe with our two highest visibility consumers.

[ddbeck]

I talked to Alexis (of caniuse) today and he gave this the green light. I think we've asked all the major consumers. I think we ought to proceed with this.

[rviscomi]

I've created #3341 to resolve this and successfully tested it as part of #3187 (review). @ddbeck do you think its also worth sharing the PR with MDN or caniuse to test on their end?

[ddbeck]

#3341 and v3.6.0 resolve this issue.