We just released v1.0 of the polyfill service. It’s taken us a long time to get to this release (well, longer than we had hoped anyway), but we’re incredibly proud of it. Here’s what’s new since our initial release:
Comprehensive test framework
We can now test polyfills using both feature detects and test suites, and as part of the service itself, make those tests available for anyone to run in a browser. We created an automation harness that runs them on Sauce Labs’ platform, allowing us to automate the verification of all polyfills in dozens of browsers.
With this in place we can be super-confident about accepting contributions from the community, because the tests are run automatically via Travis CI on every pull request. Running tests on 20 different browsers takes a while, but the confidence to merge fixes to polyfills is well worth the wait.
With the improved tests, we had a ton of new stuff to add to the docs, so we separated the docs into pages, added a better intro page with quick start code, and added a feature matrix so you can see at a glance which features we support, and in which browsers:
This is populated from the automated tests, so is kept up to date automatically as we add, update and fix polyfills.
Our docs now also include stats we’re pulling from Fastly and Pingdom to show you much the service is being used, its average response time and whether we have had any outages (so far, no downtime!).
These are nice to look at but also help show the fruits of our efforts to be smarter about caching UA-varying responses, which we do using some clever custom VCL on the Fastly CDN.
We also added a detailed contributor guide for anyone that wants to add to or improve the polyfill set. And to encourage people to help out, we’re giving away free premium access to FT content for any contributors who have a PR merged (currently any contribution qualifies, but we may add qualifying criteria in future). As well as our news content this includes all our columnists, arts and travel, and lots more. It retails for $50 a month.
Finally, we came up with a smarter way of doing variants. Polyfilling the same feature in two different browsers can sometimes require two different implementations, and we previously supported this by simply having two polyfills, with the browser as a suffix, like
Element.prototype.matches.moz. But this is complicated when users can request a feature by name, and also when different variants have different dependencies, which may also be browser specific.
Instead, we now have variations within each feature config, so that all variants can share the same name, the same detect and the same test suite, but have different implementations per browser. We can also use canonical names for dependencies.
It’s great to have got to our 1.0 release. Give it a go, give us some feedback, and if you can, get involved.