feat: add getTimeline() to expose core browser compatibility timelines

[swwind]

Description

Currently, downstream applications that consume data exported by this package cannot calculate compatibility for arbitrary custom dates offline or client-side. This is because the existing getAllVersions() function only provides data bucketed into yearly bins and static execution-date flags, losing the day-to-day progression of feature compatibility requirements. Because of this restriction, we cannot implement date-based baseline queries (e.g. baseline widely available on YYYY-MM-DD ) in non-JS environments.

This PR introduces a new exported function getTimeline() to address this limitation. It returns the chronological timeline of when each core browser version became the minimum required version.

fixes #134.

Changes

• Core Implementation: Added and exported getTimeline() in index.ts.
• Tests & Docs: Added comprehensive unit tests in index.node.js / index.browser.js and documented the usage in README.md.

[tonypconway]

Hi @swwind sorry it's taken me so long to get back to you. I'm happy to add a function to get the timeline of changes if that helps you implement the Rust library. That said, I think this actually presents a really good opportunity to rearchitect the way the module is built to be more efficient. Rather than storing all the browser releases and features from @mdn/browser-compat-data and web-features in their very reduced form the module does currently, we can reduce the footprint substantially by just storing the Baseline newly available change list.

I tinkered with this idea in the past, but didn't get round to launching it. I've spent some time over the last few days building out a more complete version that maintains the API which you can review in

FWIW,

downstream applications that consume data exported by this package cannot calculate compatibility for arbitrary custom dates offline or client-side

isn't true. The module packages enough data that you can specify arbitrary dates and get an accurate response. Take a look at the supported browsers page - if you use the "Widely available on date..." option in the drop down and change the date, the module requires no callouts to other data sources. The module doesn't import the entirety of BCD or web-features, far from it. The current ~122kb index.js size would be more like 15-25Mb depending on compression if it incorporated both of those modules entirely. #137 brings index.js and index.cjs down to close to ~50kb.

Let me know your thoughts on #137 !

[swwind]

Thanks for taking the time to look into this, and for putting together into #137!

You're right that my wording in the original PR wasn't quite accurate. The package already contains enough information to answer arbitrary "Widely available on date..." queries offline, as demonstrated by the supported browsers page. What I was trying to convey is that, from the perspective of a downstream consumer (in our case, a Rust re-implementation using the data from this package), there wasn't previously a direct way to obtain the timeline of Baseline browser changes. Reconstructing that timeline would have required enumerating dates and repeatedly querying the API, which works but isn't a particularly elegant way to extract the data.

Overall, #137 seems to address our requirements very well. The timeline representation and getTimeline() API provide a much cleaner way to consume the data from downstream applications, and the reduced footprint is a nice bonus as well. Thanks for taking my suggestion further and turning it into a more comprehensive redesign. I'm looking forward to seeing it merged.

[tonypconway]

As discussed, we resolved this in #137 in a way that substantially reduced the footprint of the module. Thanks for the suggestion!