Migrate to caniuse-lite.

[ben-eb]

Hi @Nyalab!

I've been working on an unofficial way to consume caniuse support data that is intended for modules, whereas the official dataset is intended for people. So I dropped a lot of keys that Autoprefixer & Browserslist don't use and then compacted the rest of the data. The end result weighs around 7 times less than the official database as of this writing, and the only downside is a slight performance hit when the data is restored into a caniuse format. We optimised for size, not speed, but I think we can perhaps improve this further in the future. For now the dataset is as close to caniuse-db as possible, for easy migration.

• https://travis-ci.org/postcss/autoprefixer/jobs/219404429 - caniuse-db
• https://travis-ci.org/postcss/autoprefixer/jobs/220033486 - caniuse-lite

So I think it's important to use a single source of truth for the support data, and as I am starting to make much more use of caniuse-api I'd like to update the module to use caniuse-lite too.

My only reservation about the migration is that you are using the title key from each feature. I'd like to know if that can be dropped so that we can keep caniuse-lite as lean as possible. But I would like some input from caniuse-api users, on whether they think this is necessary or not. I'm open to any feedback! 😄

Copying in users of this module/caniuse data: @agauniyal, @una, @schiehll, @sylvainpolletvillard, @MoOx, @bebraw & @ai.

Thanks!

[ai]

I think caniuse-lite is one of the best thing in frontend in 2017. With it we will dramatically reduce node_modules size around the world. Autoprefixer and Browserslist will use it in next major release.

[ben-eb]

I did some additional research into the title key, the additional cost of including it is quite insignificant (as of right now it adds 11KB total weight to the data), whereas I think not including it might negatively impact caniuse-api; and I don't believe that we should expect people to load both datasets, it should be either or.

For example, https://github.com/ZoomZhao/canidiff uses both browserslist and caniuse-db; with browserslist moving its source of truth to caniuse-lite, this module will have to load the data essentially twice; ping @ZoomZhao.

So based on this my conclusion is that we should add the title key as well to caniuse-lite. Any objections?

[MoOx]

What about letting people choose between one or the other? Anyway, node_modules for real world projet is never less than 100MB so not sure it's super important.

[ai]

@MoOx nobody block you from using caniuse-db. But from my point of view using caniuse-lite is more reasonable for everyone.

Many users complains about node_modules size and caniuse-db is often biggest dependency.

[ben-eb]

The problem with allowing choice of dataset is that people will want to choose different options and users will be stuck with even more to download; both caniuse-lite and caniuse-db, for those modules who don't agree on a single source of truth. Hypothetically speaking, we would have an even bigger mess than what we started with.

That's why I would like us to unify caniuse tools around this smaller dataset, which is specifically designed for module authors and use cases that need only the statistics that caniuse-db provides (which is most likely the vast majority).

I am currently working on a fully automated publishing/testing solution for caniuse-lite so that the maintenance cost can be handled entirely by computers, making the human cost very small (financial, mostly).

[bebraw]

@ben-eb Could caniuse-db consume caniuse-lite as a dependency? Maybe that would keep both parties happy.

[ai]

@bebraw unfortunately, caniuse-db author ignore community needs and don’t answer. I suggested him to reduce dependency size and his answer was that caniuse-db is just for Can I Use website.

So there is no way to change something in caniuse-db. This is main reason to create caniuse-lite — to solve our needs, reduce size and inconsistency.

[bebraw]

@ai Ok, sad to hear. Big 👍 for caniuse-lite then.

[ben-eb]

0.3.0 is out, includes the title key for each feature. 😃

[ai]

@Nyalab your comments will be very helpful here.

[Nyalab]

Hello everyone, sorry for the delay, i was moving houses, it is over now.

It is ok for me to switch on caniuse-lite, good job from you guys! I do not have much time right now because of the house moving, if you want to do a PR you can, i will review it as soon as i can, else i will do it when i will have some time available except when i am not making boxes 🤣

[ben-eb]

@Nyalab Cool, planning to start automated releases tomorrow, will send a PR just before this. 👍

[agauniyal]

@ben-eb nice effort 👍 . So after this change, which repo/package should we be using? This caniuse-api or some other?

Edit: Does caniuse-lite supports "CSS 2.1 properties (well-supported subset)" properties? For ref - #55

[ben-eb]

@agauniyal Yep, I think I will recommend a major release of caniuse-api because of the data source migration. However the surface API does not need to be changed. 😃

I'm waiting on a caniuse-db release to see if my publish script is working as intended and then I can recommend switching.