browser-compat-data icon indicating copy to clipboard operation
browser-compat-data copied to clipboard

Make status required for webextensions?

Open foolip opened this issue 2 years ago • 2 comments

https://github.com/mdn/browser-compat-data/pull/5816 brought the schema and documentation out of sync with regards to the status object. The documentation still says it's mandatory: https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#the-__compat-object

But in the schema, it's optional for webextensions. By making it required and counting errors, it looks like there are 1364 entries where it's not present, so about 10% of all of BCD.

The reason I noticed is because the TypeScript bindings treat it as optional, so all code has to pretend it can be missing, even if only dealing with API data.

Could we just add status blocks to all webextensions entries instead?

cc @wbamberg @Elchi3 @ddbeck from https://github.com/mdn/browser-compat-data/pull/5816 and @saschanaz from https://github.com/mdn/browser-compat-data/issues/6851. And @queengooborg.

foolip avatar Aug 05 '22 08:08 foolip

The reason that webextensions don't have a status block is because the status block would have the same standard_track, and there's effectively no real way to determine deprecation status, since web extensions are a non-standard feature to begin with. While requiring status blocks for all features would certainly simplify some of the linter and typedef code, I feel that it would create more redundant work for contributors.

queengooborg avatar Aug 05 '22 13:08 queengooborg

Can we require status blocks to be absent where we know it doesn't make sense, rather than letting it be optional? Right now there's a mix in some files. Alternatively, we can lint that all of the values are false for those entries, to have some more consistency.

foolip avatar Aug 05 '22 16:08 foolip

Yeah that sounds good to me!

queengooborg avatar Aug 16 '22 08:08 queengooborg