Would a PR making custom compat-tables easier be welcomed?

[p-bakker]

Hi,

I'm wondering if a PR that would make building custom compat-tables easier be welcomed.

I'd like to add the following options to build.js:

• specify which file to use instead of environments.json
• ability to exclude the testresults for the current browser

And then changes to build.js/master.js to hide non-applicable stuff from the UI, like:

• engines from the legenda that aren't referenced in the provided environments file
• unused platformtype headings
• unused obsolete/unstable checkboxes
• etc

Currently at least NodeJS and Rhino hosts their own version of compat-tables (containing just NodeJS/Rhino versions), based on a very old version of this repo.

Not sure if NodeJS would switch, but for Rhino I'd rather be able to build our custom compat-tables using the latest version of this repo, instead of some modified fork.

I did some prototyping and got the basics going, but before putting in the effort to make it a polished PR, I'd like to know if it has any chance of getting accepted.

Paul

[ljharb]

node itself doesn't host anything; the "node table" is one that a community member hosts. I'm not familiar with Rhino's, nor do i understand why one would exist when we already have rhino in our table.

The downside to changes like this, even if minimal to this repo, is a proliferation of flavor-of-the-week compat tables; the upside is that important tables that cover scopes different from this one would be more consistent, and we'd all get to share code.

I would think that a better approach would be to extract portions of this repo's functionality into shared packages, so that the vehicle for another table isn't "copypaste and edit the repo" but rather "install a dependency". I'd be happy to make a github/npm org to manage these, if this is the path we want to go with.

[p-bakker]

The Rhino compat tables live here: https://mozilla.github.io/rhino/compat/engines.html

nor do i understand why one would exist when we already have rhino in our table

The reasons for hosting our own version are:

• provides compat data for more Rhino versions than available on this repo
• provides an overview solemnly focused on Rhino
• will allow us to start adding the data for our next version's snapshot build

While we could provide a PR to add the compat data for the historical Rhino versions to this repo, I'm not sure if that's desired.

As for the focus on just Rhino: the compat tables from this repo are very useful if you want to see the support for a certain feature in different browsers/engines. However, if you're interested in comparing 2 different browsers or only different versions of a single browser, imho the UX isn't that great.

A custom compat table like the Rhino one serves such usecase better (besides Rhino versions we could for example also include the latest version of other server runtime to compare Rhino against)

While the ability to focus on a certain filtered subset of browsers could maybe also be added to this repo (with some deep linking mechanism), frequent updates of this repo with data for nightlies/snapshots wouldn't be great I'd think.

Whether to make the changes as i proposed or to extract reusable parts from this repo into separate npm packages, I'm not sure what the best approach is. Based on my prototype I fail to see which parts could be extracted into a separate package and still make creating custom compat tables easy: my changes, based on some commandline arguments (similar to the 'compilers' argument), slightly alters the produced html, but for the rest uses everything as is.

I could share my prototype as a draft PR if that helps

[ljharb]

I don't see any problem adding historical Rhino data to this repo.

Fair point on the rest of it.

[p-bakker]

Fair point on the rest of it.

K, so how to proceed? Share my prototype?

[ljharb]

Sure, it's worth looking at.