wintercg-specific fallback

[panva]

A lot of times I encounter the need to single a specific runtime out. For instance, all wintercg runtimes meet my criteria except node.

What I'm looking for is key setup which allows me to put specific runtimes infront of a wintercg catchall.

[Ethan-Arrowood]

If I'm understanding your recommendation correctly, I was thinking about the same thing! I want to define a wintercg key that would essentially mean "features defined by wintercg specifications" i.e. the common api proposal. The thing is though (and I do need to write more description in this proposal), this proposal is not going to define how these keys will be used, only defining that they exist and what they are associated with. The how is left up to whatever tooling folks want to build.

[panva]

Understood, we are on the same page. The how can very much be informed by the description of this "wintercg" (or whatever it ends up being) key.

[sheplu]

also should we in the future have some kind of list with all the runtimes and a Yes/No compliance on all features ? Or should we expect runtimes to add to their doc that they are compliant ?|

Looking at JavaScript and browser history I do think it is better to have us do it as this would be neutral (a bit like caniuse for example)

[Ethan-Arrowood]

I believe as soon as we have a technical WinterCG proposal (such as the incoming Fetch work), we can also develop a set of web platform tests for compliance checking. Generally, it is up to platforms to state their level of compliance. Would love there to be an integration with caniuse or have our own site that automates and shows compliance for various open source runtimes 😄

[Jarred-Sumner]

We'd be open to adding "wintercg" to the list of export conditions bun reads from (or some other export condition name that is agreed on to mean "server-side runtime")

[styfle]

It sounds like #5 will cover this use case, right?