cluster: update deprecated API #13704
Conversation
|
If this gets push back, #13703 could be considered, as it's even less major. |
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
Should we consider removing the phrase from the error code?
There was a problem hiding this comment.
Unfortunately I think it's necessary for context, otherwise those seeing the deprecation error and not having any context won't really have a clue what it is about, or any ability to find out. The whole reason deprecations.md exists is to provide that context when necessary.
There was a problem hiding this comment.
it can be a reference though right? like give you a url to check the extended documentation?
There was a problem hiding this comment.
This is the extended documentation. This message is in deprecations.md, this is not the warning message that is printed to the console.
|
@jasnell I can't think of any noticeable negative consequnces of this spefic PR, but I am not fully convinced that the property should be entirely removed in 9.0 yet. |
lib/internal/cluster/worker.js
Outdated
There was a problem hiding this comment.
I am not sure yet that the correct action would be to remove the property entirely in 9.0.
Apart from this comment, this change looks fine.
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
Nit: an unfortunate decision was made to add a boolean property with the name -> there was a boolean property named
unfortunate appears a couple sentences later so we can remove the repetition of the word here without losing content
There was a problem hiding this comment.
I can update that in whichever one of the PRs is landed first then cherry-pick the updated commit here.
lib/internal/cluster/worker.js
Outdated
There was a problem hiding this comment.
This will cause people to see warnings like (node:4680) DeprecationWarning: Please use worker.exitedAfterDisconnect instead., which is completely uninformative.
There was a problem hiding this comment.
Understood, and in general I agree that it's not ideal, but this is about finding a compromise that avoids the original problem. The reason deprecation codes were added is to provide a mechanism for finding the context if necessary.
There was a problem hiding this comment.
If someone sees the warning and decides to find the context, they'll see the word anyway. The only case where hiding it here would help is when the warning is perpetually ignored.
There was a problem hiding this comment.
It will be (node:4680) [DEP0007] DeprecationWarning: Please use worker.exitedAfterDisconnect instead. and that easily googleable.
We can't eliminate all references, but putting it one step further is good IMHO.
(at least it won't be repeated over and over in the logs)
There was a problem hiding this comment.
It's hard for me to imagine a scenario where it would be repeated over and over in the logs, as the warning is one-time per process.
There was a problem hiding this comment.
That's the paradox of this whole situation... see (content warning) Unitech/pm2#2780
jasnell
force-pushed
the
update-deprecated-api
branch
2 times, most recently
from
f05dbdf to
8a0f530
Compare
|
ping @nodejs/ctc |
jasnell
force-pushed
the
update-deprecated-api
branch
from
8a0f530 to
704428e
Compare
Make deprecated property non-enumerable, remove from docs
jasnell
force-pushed
the
update-deprecated-api
branch
from
704428e to
6f73f4f
Compare
|
Updated the language in the docs a bit. |
|
CI failure is unrelated. |
PR-URL: #13704 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Myles Borins <[email protected]>
PR-URL: #13704 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Make deprecated property non-enumerable, remove from docs PR-URL: #13704 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Myles Borins <[email protected]>
10 participants
This goes along with #13702 and is part of the alternative for #13684
Mark the deprecated API non-enumerable, remove from docs, and update the deprecation message.
Technically, marking an API non-enumerable would be semver-major, but I'm proposing this as a semver-patch. The deprecated API is still there, existing code should not break as it's extremely unlikely that existing uses of the API are depending on it being enumerable.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
cluster