Initial Proposal #2
Conversation
|
Using |
This is almost exactly why we are creating this proposal 😄 It is currently ambiguous and vague what folks should be using. And since it is not standardized every tooling makes up its own rules. Node says you can use a variety of keys, Webpack has its own list, etc. By listing them here, and encouraging tools to adopt this standard, at least there will be no more confusion and vagueness. While yes "edge" is a commonly used word in this space, no other runtime is branding and marketing itself as Vercel's Edge Runtime is and it was what was decided upon internally at Vercel. If there is hard push back from the group, I will bring the feedback back to Vercel for discussion. |
|
I'll go ahead and add a stub now! Do we have anyone from Netlify involved in WinterCG? Anyone specific I should reach out too? Otherwise, I will open a discussion thread like I did for React Native |
|
I'll get you someone. I also have concerns about using
Then there are also other products that use "edge" as a concept in marketing material:
|
Since the browsers wouldn't necessarily be concerned with what we are working towards here in WinterCG it could be weird to have them on the list. I think generally, we are trying to create the list of server runtimes so that we can leverage the same tooling browsers have benefited from (i.e. browserlist) previously. |
|
Sure - but we'd still want to make sure that server runtime keys didn't conflict with what users might want to name their browsers, and it seems the simplest way to do that is to include them here? |
Good point! Is there an existing standard for those browser identifiers? My assumption is that the tooling we are looking to improve with this key set is currently not concerned with specific browser bundles. Like even Webpack only has a |
|
The closest is likely https://github.com/browserslist/browserslist |
Co-authored-by: Jordan Harband <ljharb@gmail.com>
|
Instead of having browsers in the list, we add some text to also avoid conflicting with browsers defined in browserlist to prevent tooling conflicts. This way we aren't responsible for getting any sort of browser buy-in or maintenance |
|
That sounds perfectly reasonable! |
|
@Ethan-Arrowood ... let's not list anyone next to the |
|
To be clear, my sign off on this PR is from my POV as representing cloudflare workerd, not Node.js |
|
Okay removed myself. I was planning on opening an discussion in the tooling group anyways so i'll link to that instead when I do. Luckily, they should be an easy one as |
|
Does anyone have more input into the criteria for being on this list? I've intentionally left that section vague since there is value in not having a large set of restrictive rules (so any runtime can be included), but I can also see some value in setting stricter expectations. Some things that come to mind are:
I'm not proposing that we need to set more than what I've written so far, but want to share the thought so it can be discussed 😄 |
index.bs
Outdated
|
|
||
| Repository: [https://github.com/facebook/react-native](https://github.com/facebook/react-native) | ||
|
|
||
| ## Netlify - Edge Functions ## {#} |
There was a problem hiding this comment.
| ## Netlify - Edge Functions ## {#} | |
| ## Netlify - Edge Functions ## {#netlify} |
should we at least have a temporary naming for this one ? and same for key. I think we choose for others runtimes without having someone from the company so why not here too ?
There was a problem hiding this comment.
Other ones were pulled from existing resources or told to me by someone from that project. I've reached out to someone from Netlify so they will be checking out soon
|
I think we should have some restricting rules - at least some basics one. I am not sure that if I build a runtime only for me / private it is interesting to have it listed here. |
|
I don't understand the purpose of proposing these keys in the first place. Seems as though "runtime keys" should be scoped to the concerns of wintercg: implementation of common runtime API's. If company X builds a "runtime" on top of Deno, it's not a new runtime, it's still Deno. If WinterCG introduces a new API, it's Deno that needs to implement it, therefore company X's "runtime" doesn't belong on the list. "where the WinterCG implementation lives" should determine if something deserves a runtime key. The goal isn't "bundler tooling interoperability", it's runtime interoperability, and at no point would runtime code that's interoperable need to check a runtime key. Just to clarify I'm not talking about "edge-runtime" naming, I'm talking core reason these keys exist. |
|
If And if it's meant to be independent, shouldn't it include maintainers (not just contributors) representing multiple parties? |
|
For folks new to this proposal, the albeit short history started from the idea of how do we expand the usage of To summarize that part, there is already developer tooling that lets you specify "my project needs to run in Node version 16+" or "use this file when you run my module in the browser, and this file when you run it in node". Now that we have so many new runtimes being developed such as Workerd, Deno, Bun, Edge Runtime, etc. we wanted a clear way to define what key can be used to represent those runtimes in these same fields. The simplest way to do so was to create a proposal that acts as a living registry. This specification contains the language necessary for the keys to be added, modified, and deprecated over time. It enables developer tooling to build around a defined list just like |
|
Why is it not based off of who owns the implementation / what the actual runtime is? I.e, we are going to continue to see an explosion of cases like the following unless the criteria for being on this list becomes "I own the WinterCG API implementations": swtich (runtimeKeyProposal) {
"cloudflare":
"vendor-a-edge":
"vendor-b-edge":
// same
break;
"deno":
"vendor-c-edge":
"vendor-d-edge":
// same
break;
"bun"
"vendor-e-edge":
"vendor-f-edge":
// same
break;
// ...etc
}I don't need 50 more keys to add to a bundler's "exports" / "imports" configuration. |
|
That is the benefit of this proposal. It does not dictate how tools need to utilize the list. All it does is specify the registry. It is up to (figuratively) you how you want to use these keys. Are you a tooling author creating a bundler that supports Node, Deno, CF, Bun, and more? Maybe this list and a lengthy export list in package.json is important. Are you a module author creating an library meant to run only in Node? Okay great, specify "node" in your exports and call it a day. Maybe you are a module author creating a library meant to run across node, deno, etc... then you definitely care about this registry so you can precisely specify what export files match with what. |
|
I will reiterate that we have been very intentional with the language used in the proposal. We do not want to be telling anyone to do anything; we are simply making this information publicly available in the most consistent and openly collaborative way possible. For the overall benefit of all developers working in the budding web runtime space. |
|
Fair enough. I then ask those on the list to reconsider if they need their own key or fall into an existing key. Specifically if you do not own the WinterCG API's or the module loading system. |
|
@jacob-ebey I've made the proposal to also add a catch*all key to represent "any runtime that satistisfies the WinterCG minimal API". Such that runtimes that do just that and nothing on top can rely on that and also that library authors that don't need any specific runtime's API don't need to keep on adding unique vendor specific keys to their declaration files. |
|
Yes! #1 it was actually the very first issue in this repo ✨ We just want to be intentional what It is something to be discussed and iterated on in the future for sure |
|
Just want to verify that we are not specifying runtime API compatibility with this, but rather what runtime owns specific keys for "exports" / "imports". Seems outside of the stated goals of WinterCG, or am I still misunderstanding? |
|
I believe you are misunderstanding. The goal of the Minimum Common API is to specify runtime API compatibility. Other specs and proposals in this group have other goals |
|
Our charter accurately established our the groups goals:
|
Yes, this is articulated in the specification: https://github.com/wintercg/runtime-keys/pull/2/files#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R31-R33 If you believe this can be better articulated please leave some feedback! |
|
Is the second part to the quote you cut short accurate?
Beyond that it feels like this proposal doesn't accomplish much, and if it is in fact part of, if not the whole goal, the number of keys should be limited and not open for anyone who forks a runtime, otherwise that switch statement above will just grow and grow with more unique keys with the same underlying meaning. |
|
As I've mentioned previously, this proposal is not dictating how they are meant to be used. It is acting as a registry to be used however folks see fit. That is the purpose of this proposal. If you disagree with the effectiveness of this proposal you are welcome to ignore it and build your tools and modules however you see fit. |
|
Discussed in today's meeting:
|
|
Hello all, I'd like to propose adding the following runtime keys as discussed in the previous teleconference. ##Alibaba Cloud - edge-routine## {edge-routine} |
|
Hi folks, I've adjusted the proposal to reflect recent feedback. Summary:
We are still in the process of rebranding, but this new name and key represents our intended changes. Thank you again for the feedback! |
| Keys {#keys} | ||
| ============ | ||
|
|
||
| ## Alibaba Cloud - edge-routine ## {#edge-routine} | ||
|
|
||
| The JavaScript/Webassembly runtime that powers Alibaba Cloud edge-routine. |
There was a problem hiding this comment.
is it JavaScript/Webassembly ? or just JS ? (I don't find any reference of webassembly on the doc - but only did a quick search)
There was a problem hiding this comment.
Just copied this comment: #2 (comment)
There was a problem hiding this comment.
is it JavaScript/Webassembly ? or just JS ? (I don't find any reference of webassembly on the doc - but only did a quick search)
It is JavaScript/Webassembly. Currently, there is no doc for Webassembly but the doc will be updated to add Webassembly shortly.
Co-authored-by: Jean Burellier <sheplu@users.noreply.github.com>
|
Hi, as discussed on the WG chat, I would like to add another key for Lagon, an open-source runtime and platform I'm working on. This project is not backed by a big company or a VC but is bootstrapped and driven by the community. It's currently in development but will be stable in 2023: |
This PR adds the initial proposal.
Before this is merged, we need to seek approval from the various runtimes represented in this initial draft. The following list matches the list of keys included in this initial draft. Each runtime is either linked to a discussion/issues/post requesting approval from the relative project, or someone apart of WinterCG who can represent the runtime is tagged.