Plan of process.binding() deprecation

オープン
  • 何か問題がありますか？
#1,482 コメント 18 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
javascript, node.js
領域
backend

調査の方向性

まず、参照されている Node.js の pull request と、最終状態の動作、binding のロールアウト、代替案、警告のタイミングに関する質問を確認します。TSC がこれらの質問を解決し、合意された deprecation plan を文書化すれば完了です。実装ファイルやテストは指定されていません。

索引モデルが issue の本文から書いたものです。

説明

This issue is not new but motivated by https://github.com/nodejs/node/pull/50687, which proposed to

  1. Ship the runtime deprecation in Node.js v22 --deprecated-process-binding on by default.
  2. --no-deprecated-process-binding becomes the default in Node.js v23
  3. process.binding(...) is removed entirely in Node.js v24, with the CLI option becoming a no-op

For background in 2021 the plan suggested in https://github.com/nodejs/node/pull/37485#pullrequestreview-600060802 and followed since https://github.com/nodejs/node/pull/37819 was:

  1. Do comprehensive research into what exact features ecosystem modules get through process.binding() (this isn't actually going to be a huge API surface!)
  2. Patch process.binding() so that it returns objects that cover those use cases, implemented in terms of public APIs
  3. Optionally, runtime-deprecate process.binding() only for the cases that users aren't commonly encountering
  4. Eventually, remove support for those cases specifically
  5. Leave it at that, don't runtime-deprecate process.binding() as a whole and leave the shim in place forever

I am opening this issue trying to slice the issue into different questions instead of bundling all together into just two different plans, in the hope of figuring out a better compromise.

There are several questions to the deprecation of process.binding():

  1. What's our end-goal when the deprecation reaches EOL?
    a) Delete process.binding completely so that when trying to invoke it, users get an error.
    b) A function that does no more than emitting a warning and returning empty objects. Users almost always get an error when they try to access an unsupported property, but if the code path is unused, e.g. only loading a process.binding() from the top-level but never actually hit the code path using anything from it, it would not fail.
    c) Leave a low-maintenance and harmless shim in place forever. Users get an error only when they try to use a specific unsupported property.
  2. How should the list of bindings (currently 20) be deprecated?
    a) Individually, based on how problematic they are/how difficult it is to provide alternatives
    b) Together at once
  3. Should the runtime deprecation start before or after alternatives/shims are completed
    a) We investigate the impact (e.g. through CITGM), develop and release alternatives on the way, monitor the changes in the impact, before deciding when it's ready to runtime-deprecate it (individually or all together).
    b) Runtime-deprecate it directly and mitigate the impact afterwards based on the bug reports/feature requests we receive.
  4. How should the warnings be rolled out when we start to emit warnings (there are a few more combination possibilities with 2)
    a) Emit runtime warnings unconditionally
    c) Non-node_module warnings first, node_module warnings in the next cycle

I think we as @nodejs/tsc need to take a deeper look into these questions and make some decisions before finishing a plan of the deprecation.

主要言語
JavaScript
スター
693
フォーク
142
平均マージ
8日 7時間
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nodejs/TSC のほかの issue

nodejs/TSC の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。