anandthakker / doiuse

:bomb: Lint CSS for browser support against caniuse database.
MIT License
1.23k stars 50 forks source link

Using MDN Data #163

Open RJWadley opened 1 year ago

RJWadley commented 1 year ago

Not all features are in the caniuse database (e.g. #161). So, we have to use MDN data during detection somehow. I'm just not sure how yet, so I'm gonna dump my thoughts here. Open to any and all thoughts, feelings, comments, and etc. There's definitely more options than just these :P

Option 1: Use MDN for detection instead of caniuse. Quite a bit of work, but potentially a clean solution.

Pros:

Cons:

Option 2: Convert any missing MDN data into caniuse's format and pretend it exists in caniuse-lite

Pros:

Cons:

clshortfuse commented 1 year ago

I've been messing with a prototype offline where we read straight from the JSON. I took the reading of raw json update-features had and changed it to import JSON as an object (edit).

https://github.com/anandthakker/doiuse/blob/2ad9e2b63d86d936fd395d7c4d757b8eff3b661d/scripts/update-features.js#L7

I'm thinking, and been messing around with, reading straight from caniuse-db and mdn's JSON files. Because it's an ESM import, it should technically be possible to tree-shake it, including only the parts of the JSON we need. That tree-shaken version is what gets published to NPM.

We don't need to pull in caniuse-lite except for whatever extra they have. The actual entire caniuse-db DB is 3MB, whereas caniuse-lite is 2.7MB. We're not saving much here. If we can get a workflow going, it can automatically update from MDN and caniuse-db as needed, as well as publish. It would dynamically change the way we code our selectors since MDN gives very fine tuned data.

That's kinda where my head is at now, but haven't had time to make the proof-of-concept.