diagnostics_channel: add a channel for filesystem operations
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 45/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- javascript, node.js
- 領域
- api, operating-systems
調査の方向性
公開されている node:fs と node:fs/promises の API、および既存の node:diagnostics_channel の TracingChannel 規約から始めます。sync、callback、promise、stream、filehandle の各パスを比較します。FSReqCallback の詳細に依存しないようにしながら、公開レイヤーとチャネル名を確定します。対応する公開ファイルシステム操作が、文書化されたライフサイクルイベントとメタデータを公開すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
What is the problem this feature will solve?
node:diagnostics_channel does not currently expose a built-in channel for filesystem operations performed through node:fs and node:fs/promises.
The proposed scope is the public filesystem APIs. Calls made directly by native addons or arbitrary native code do not need to be included in this contract.
What is the feature you are proposing to solve the problem?
Add a built-in tracing channel family for filesystem operations. One possible naming scheme is:
tracing:fs.operation:starttracing:fs.operation:endtracing:fs.operation:asyncStarttracing:fs.operation:asyncEndtracing:fs.operation:error
The shared event object could contain:
operation: a stable operation name such asopen,read,stat,readdir, orrealpath.api:sync,callback,promise,stream, orfilehandle.- Path, source/destination, or file descriptor fields when applicable, preserving the value type passed by the caller.
resultanderrorfollowing the existingTracingChannelconventions.
Large read/write buffers should not be copied into event metadata. The exact publication layer—public API wrappers or the lowest shared internal filesystem layer—can be determined during implementation, but the documented payload should remain independent of internal FSReqCallback details.
Using one operation family with an operation field avoids requiring wildcard channel subscriptions while allowing subscribers to filter individual operations.
What alternatives have you considered?
Wrapping exports from node:fs and node:fs/promises is incomplete when references have already been captured and requires synchronization with named built-in ESM exports. async_hooks exposes asynchronous resource lifecycles rather than stable filesystem operation semantics and does not cover synchronous calls. Trace events use a different consumption API and payload contract.
- 主要言語
- JavaScript
- スター
- 122k
- フォーク
- 37.4k
- 平均マージ
- 4日 3時間
- マージ済み PR(30日)
- 279
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
nodejs/node のほかの issue
-
doc
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
build
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
feature request
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
palladius/rails8-app-on-gcp#145 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
dotenvx/dotenv-vscode#139 ·
-
test-change-proposal
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
web-platform-tests/interop#1455 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
corsairdev/corsair#1764 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100