-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib: promote process.binding/_tickCallback to runtime deprecation #50687
lib: promote process.binding/_tickCallback to runtime deprecation #50687
Conversation
Review requested:
|
dc149cd
to
957fc0f
Compare
These have been pendingDeprecation for long enough. This also adds the `--deprecated-process-binding` (and matching `--no-deprecated-process-binding`) CLI option as a future transition path for when we do ultimately remove `process.binding()`. `--deprecated-process-binding` ensures that `process.binding(...)` is available and is currently the default. In the future, when we are ready to begin moving `process.binding(...)` to EOF, we can flip the default so that `process.binding('...')` is unavailable by default *but still able to be switched back on if necessary*, giving users an escape hatch if they really need it. This will give us a more nuanced path than abruptly removing it completely.
957fc0f
to
aed9d49
Compare
I think we should have alternative suggestions before we runtime-deprecate these. Otherwise I very much suspect that these are used commonly enough that no migration would be done (because there aren't alternatives) and many users would just disable the warnings.... |
What kind of alternative suggestions would you have in mind? I'm afraid that unless we just go ahead and proceed with runtime deprecating these there's never going to be enough pressure for the ecosystem to actually move off of them. As it is these are already quite dangerous to use. |
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
"These" can be a bit too generic - |
I remember many years ago that was the intended plan but there never seemed to be any follow up to complete that kind of effort, and it seems obvious that having it behind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@@ -144,6 +143,9 @@ const experimentalModuleList = new SafeSet(); | |||
{ | |||
const bindingObj = { __proto__: null }; | |||
|
|||
// TODO(@jasnell): If the --deprecated-process-binding option is false we really |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just expose the processBindingAllowList
list, which is set to empty initially, and add things back in pre-execution. We do something similar for --expose-internals
for example.
// Ideally it wouldn't be defined at all already but realm.js does not | ||
// provide a means of checking to see if the option is enabled or not, | ||
// so we do it here. | ||
delete process.binding; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should at least throw a warning and tell users about the option --deprecated-process-binding
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we haven't done the due diligence for this change. If the reason for abandoning the incremental plan is that it's not moving, then I suggest we:
- Open a tracking issue for auditing
processBindingAllowList
and moving them tolegacyWrapperList
with wrappers added inlib/internal/legacy/processbinding.js
- Ask for help in the audit - this look like a list of good first contributions to me. The rule can be simple - existing read-only constants and side-effect-free helpers can be exposed as-is before we think about alternatives. Any method beyond that gets filtered out. If somehow this causes significant regression, we can get the filtered stuff back out quickly and add a TODO for proper alternative - which can just be semver-patch. This also helps to make sure that no new additions to the bindings are going to end up accessible to the user land going forward.
- We set a deadline for the audit. This won't be released until next April anyway. I think we should defer the deadline until at least next February. When the deadline comes, for any of the bindings still in
processBindingAllowList
,process.binding
returns an empty object and emits a warning if--deprecated-process-binding
isn't set, or return the original one if the flag is set. Eventually,process.binding()
should just return a list of harmless wrappers. We can revisit whether we should delete this list of harmless wrappers in the future.
If we get some help in the auditing, 4 months look enough for auditing to me.
Related work #48568 |
@joyeecheung I think it's a solid plan if we can get volunteers for the audit. Can you open a "call to action" issue describing what needs to be done? |
I think I'll need consensus that this is the path instead before I open such issue to avoid making contributors confused/waste audit work. Should I call for a vote or something? |
We may need one, yes. Not sure how else we'll come to consensus here. |
Discussed again in the TSC meeting, the idea agreed on is to open an issue in the TSC repo regarding the plan of
I'll try to come up with a an issue that summarizes the options and get a vote together (maybe on the steps first before we combine the steps together to form some plan to vote on) |
Moved to nodejs/TSC#1482 |
These have been pendingDeprecation for long enough.
This also adds the
--deprecated-process-binding
(and matching--no-deprecated-process-binding
) CLI option as a future transition path for when we do ultimately removeprocess.binding()
.--deprecated-process-binding
ensures thatprocess.binding(...)
is available and is currently the default. In the future, when we are ready to begin movingprocess.binding(...)
to EOF, we can flip the default so thatprocess.binding('...')
is unavailable by default but still able to be switched back on if necessary, giving users an escape hatch if they really need it. This will give us a more nuanced path than abruptly removing it completely.The current transition path would be:
--deprecated-process-binding
on by default.--no-deprecated-process-binding
becomes the default in Node.js v23process.binding(...)
is removed entirely in Node.js v24, with the CLI option becoming a no-op/cc @nodejs/tsc