node-api: include experimental feature flags in add-on version reported at runtime
まだ誰も着手していません。
- 主要言語
- JavaScript
- スター
- 122k
- フォーク
- 37.3k
- 平均マージ
- 4日 2時間
- マージ済み PR(30日)
- 283
説明
This only applies to features that change the behaviour of existing APIs.
We currently have two flags for each experimental behaviour-changing API:
- A feature flag indicating that it is available within the
NAPI_EXPERIMENTALportion of the API. - An opt-out flag indicating that, although the add-on chose to use
NAPI_EXPERIMENTALit does not wish to use this particular feature of the experimental bundle.
In order to avoid going down the experimental code path when running an add-on that chose to opt out of an experimental feature, we need to encode that choice in the version reported to the add-on loader.
If NAPI_EXPERIMENTAL is defined, all experimental features are turned on, unless, for any given feature, its opt-out flag is given.
We can include experimental flags in the version number reported at runtime as follows:
| highest 16 bits | lowest 16 bits | |||
| feature 1 | feature 2 | ... | feature 16 | NAPI_VERSION (latest released, i.e. 8, 9, 10, etc.) |
| or | ||||
|---|---|---|---|---|
| NAPI_VERSION_EXPERIMENTAL (2147483647) All experimental features are requested | ||||
This value ends up on napi_env. At runtime we can check against the bits of this value to decide on the code path. We should probably create a family of macros for making decisions based on the feature flags.
At our Node-API meeting we concluded that we should introduce behaviour-changing features extremely sparingly, because, in order to ensure we do not break our users, even those that have opted into NAPI_EXPERIMENTAL, the testing complexity doubles with each feature we introduce.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
実装ファイルやテストは指定されていません。まず、Node-API のバージョンが napi_env に到達する経路と、実験的機能が実行時にどのように表現されるかを追跡します。報告されるバージョンにオプトアウトの選択をエンコードし、リリース済みバージョンの動作を変更せずに、提案された feature flag のチェックを提供できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- node.js
- 領域
- api
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 30/100