Revert "doc: promote fetch/webstreams from experimental to stable" #49867
Conversation
This reverts commit 740ca5423aabc06af48f6dacfb17335bbaa25c0c1. At minimum, this needs more discussion. Refs: nodejs/undici#1737 (comment)
|
There doesn't seem to be any discussion going on, but I would like to continue it. Not sure what else there is to discuss because my position hasn't changed but I can reiterate what I've said, I guess, if anyone doesn't want to read a hundred posts. lol |
mcollina
added
the
tsc-agenda
What are you proposing, exactly? I think there isn't support for keeping things experimental forever. Is there some other status that would better represent our stability guarantee other than calling this stable? |
|
So can you open a PR to propose an implementation of that? |
|
I haven't gotten a response as whether it's a good idea, or at least an acceptable alternative. There were people who were against adding a new stability index earlier in the discussion but they seem to have stopped responding (I don't blame them, very few people have reason to care about this). |
|
Well, opening a PR is one way to force the issue. If they don't care enough to respond they probably don't care enough to object. Personally I don't think we can leave things as experimental forever. Our users want a stability guarantee. So if fetch needs breaking changes more frequently than in each major, please propose a new stability level to describe what exactly that means. I think drafting a PR is the best way because then we know exactly what you're proposing and we can debate the PR text. |
|
I'm -1 because we can't leave things experimental forever. If we need to loosen the definition of "stable" to compensate for semver-major spec changes, let's do it. |
|
Should the definition of stable be loosened, or should a new stability index be added? Loosening it might cause more breaking changes, which might be wanted (going on some recent twitter discussions)? @GeoffreyBooth I can't promise that I will make a PR, I'm very busy currently unfortunately. From the undici discussion, no one wants to keep it experimental forever, it's just that experimental is a better label, currently, than anything else. |
|
The way I see it: stable means that we don't ship breaking changes. If we implement a breaking fetch change then that should be a semver major for undici and we only bring in semver major changes into node when doing semver major in node. If someone needs the latest, greatest and most web compatible fetch implementation they can use the undici package directly. |
|
but then we have potential issues where we cannot land undici PRs in node core for months to a year still, and LTS releases are screwed too. Node core also now exposes WebSocket from undici which means by association we can't land fixes for it either, although it's experimental. |
|
I don't see a problem. Use the npm package if you need the latest. I don't think this is an issue in practice for web socket. If and when it becomes an issue I'm happy to reconsider. |
This might be a good compromise. We could at least mention this in the docs, with examples, like “here’s how to override Node’s global with the version from your locally installed Undici”. |
this is already an issue, there's already a breaking change to fetch that can't land in undici because fetch is stable 😐 |
|
It's also not a great compromise - why make fetch a global if there's a serious need to override it (whether it's security, being up to date, bug fixes, etc.)? I mentioned this in the undici issue. |
Land it and we make a semver major release of undici? Also might make sense to move all the web spec stuff into separate repo. |
IMHO. The only need for global is for isomorphic usage. And that people expect it. |
|
Not saying this is an optimal situation. But I don't see a better alternative. |
ronag
removed
the
tsc-agenda
This reverts commit 740ca5423aabc06af48f6dacfb17335bbaa25c0c1.
At minimum, this needs more discussion.
Refs: nodejs/undici#1737 (comment) (discussion starts here)