ノードパッケージをZIPファイルにまとめられたらいいのに。そうすれば、Windowsで小さいファイルにアクセスする際のセキュリティやメタデータの負担を避けられるし。

ノードモジュールフォルダのファイル数はクレイジーだね。あの混沌を整理できる方法があれば大歓迎だよ。

Firefoxが似たような理由で全てをjarにまとめ始めたのを覚えてる。

コードにバンドラーをかけて、すべての（静的）インポートをインライン化してツリーシェイキングするのはどうかな？

Yarnのような代替パッケージマネージャーは、各Nodeパッケージを保存する方法としてZIPファイルを使ってるよ。

Nodeの動作がどうなってるのか、マジで信じられない。Zipファイルの方がずっと分かりやすいし、Yarnのその点が好きだったな。

ZIPから直接depsにアクセスするのって、ほんとに速くなるのかな？ちょっと驚くけど、RW用に設計されたファイルシステムで読み取り専用なら、そんなに意外でもないかも。そうじゃないなら、tarでいいんじゃない？

NTFSのペナルティを避けるために、仮想化されたLinuxを使うのもアリだよ（WSL2、VS Codeの開発コンテナとか）。

npmがプロジェクトごとのnode_modulesを採用することにしたのは、Rubyや他の言語のように共有するのではなく、開発者に優しくて高いカスタマイズ性を持たせるためだったと思う。それが実現できてるし、package.jsonもそれ以上のものになったから、個人的には素晴らしいシステムだと思ってる。Atom（Pulsar）みたいなハッカブルなIDEと組み合わせると、ウェブ開発者にとってはかなり良い開発体験になるね。

挙げられた4つの理由のほとんどは、悪い設計判断を緩和するためのものに聞こえる。ブラウザのJavaScriptは、ずっとこの道を歩んできた。新しい標準が導入されるのは、実際には達成不可能だった新機能を追加するためじゃなくて、愚かな人々のために解決策を提供するためだった。VFSには元々の利点があると思うけど、悪いアプリの判断を除けば、それはほんのわずかだね。ちなみに、JavaScriptはインメモリデータベースから恩恵を受けると思う。これはNode.jsの強化というより、言語の強化になると思う。JSのロジックを使って1つ以上のオブジェクトやレコードを返すオブジェクト/配列ストアが言語にネイティブであれば、アプリケーションの能力が広がるよ。SQL言語も、オフラインストレージに保存したくないもののためのサードパーティのデータベースも必要ない。

それに対して言語の拡張を求める理由は何？ただJSコードで書けばいいじゃん。（あるいはWASMとか）

> ちなみに、JavaScriptはインメモリデータベースから恩恵を受けると思う。 それってただのグローバルステートじゃない？それとも、永続的にしたいってこと？

> JavaScriptはインメモリデータベースから恩恵を受けると思う。そのデータベースはおそらくJSONオブジェクトに似た形になるんじゃない？グローバルなJSONオブジェクトでは解決できないことを提案してるの？

NodeでIndexedDBみたいなのってある？

Nodeが「ランタイムで生成されたコード」をインポートできるようにするのが本当に良いことだとは思えない。セキュリティの観点から、ちゃんと手続きを踏んで読み込むべきだと思う。ファイルシステムをモックするアイデアは好きだけど、それはNodeの一部じゃなくて、テストスイートの一部であるべきだと思う。最後の方の例で、sqliteプロバイダーにデータを保存してからJSONファイルとして保存するのは、ちょっと驚きだね。特に、ディスクに保存しないことが目的のシステムなのに。多分、ただの悪い例かもしれないけど、これが単に複雑さを増すだけじゃない理由を本当に理解しようとしてる。

でも、「ちょっと待って、ESMは存在しないの？」って思うと、4番目の議論がそもそも真実じゃないことに気づく。実際には、2020年から利用可能な同じ動的インポートを使って「一時ファイルを書く」代わりにblobを作成することで、この議論が言ってることができるんだ。

node -e "new Function('console.log(\"hi\")')()" か、もっと言うと node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c + 'console.log(exports.say({ text: \"like this\"}))')())" これは特にヤバい。なぜなら、umdがグローバルオブジェクトをいじるから。だから、これが動く node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c)()).then(() => console.log(exports.say({ text: 'oh no'})))" ってのは。

メモリにしか存在しないモジュールをインポートしたりrequire()したりすることはできないよね。でも、データURLに変換してインポートすることはできるんじゃない？

そうなんだけど、Claudeはこのブログ記事を書くときにその提案はしなかったし、全部やったからさ…

相対インポートはどうなるの？

これがNode.jsのコアに役立つ追加になるかどうかは置いといて、19,000行のPRはほとんどClaude Codeによって生成されて、提出者によって手動でレビューされたってことは、プロジェクトの精神に反してるし、プロジェクトのCONTRIBUTING.mdに設定されている開発者の証明書の条件に直接違反してると思う。

言うことは聞け、やることは真似するな。もっと真面目な話をすると、これがマージされる前に徹底的にレビューされると思うし、Nodeにはこれを監視するセキュリティチームがいるからね。

具体的にどうやって開発者の証明書の条項に違反するの？

大きなPRは、Linuxカーネルの開発者リストが従っているようなプラクティスを取り入れるといいかも。大きなサブシステムの変更は、理論的には受け入れられる前に、提出者がテストやメンテナンスのためにしばらく別々に管理することもあるしね。大きなコード変更は、レビューやメンテナンスの目的で意味のあるコミットに分けられることが多い。AIがPRの行数を増やしてるから、もっと多くの開発者がこのスキルを磨く必要があると思う。大規模な変更を自分でレビューするために、どうやって部分的に体系的にレビューしたいか考えて、PRを意味のあるコミットに分けるのが良いよね。例えば、インターフェース、ドキュメント、変更された実装のサブセットとか。

mcollinaがNode.jsの技術運営委員会のメンバーであることは、覚えておく価値があるね。

この意見には完全に反対だな。PRでAIの支援を許可しないと、将来的にプロジェクトが壊滅的な状況になると思う。他の選択肢に比べて、迅速なイテレーションができなくなるからね。ちなみに、OpenJSのエグゼクティブディレクターが、Node.jsへの貢献にAIの支援を使うのは大丈夫だと言ってた。法務にも確認したけど、AI支援の貢献に関しては財団も問題ないって。これを文書化する方向で進めるよ。

痛みは信号なんだ。たとえその対処法が気にしないことだとしても、火に手を焼くのはやめた方がいいよね。痛みは、怪我をしないように助けてくれるものだから。自分の問題解決法がすごく痛いけど、痛みに耐えられるって自慢するのは賢いとは思えない。他の人はまだその痛みを感じるからね。このコードはホスティングに帯域幅を使うし、デバイスのスペースも取る。メンテナンスする人にとっては、ファイルシステムAPIを進化させるための作業が永久に倍増するんだ。もし他の誰かが同じような考え方を持っていたら、その倍増したコストをさらに倍にするかもしれないし、誰かがそれを8倍にするかもしれない。結局、誰も他の人に渡している痛みを感じていないからなんだよね。

自分や自社内で使うコードにClaudeを使うのはいいけど、こういう広く共有されるプロジェクトに注入し始めると（LinuxカーネルやDebianとか）、プロジェクトが汚染される感じがどうしても残るよね。個人的な意見だけど、あまり人気がないかも。もしこれが受け入れられる前例になるなら、24.14以降のNode.jsのアップグレードはしばらく避けるつもり。

Denoを好む理由の一つは、IndexedDBが使えるからなんだよね（他にも色々便利なものが標準で揃ってるし）。

依存関係を減らすことを試みてみたらどう？11tyは正しい方向に進んでると思う。いくつかの依存関係を大幅に削減したり、依存関係のないパッケージに置き換えたり、プラットフォームの機能を使ったりして、すぐに使えるものになってるよ。

> 「AIを面倒な部分に使ったんだ。14,000行のPRを可能にするけど、誰も手書きしたくない部分、例えばすべてのfsメソッドのバリエーション（sync、callback、promises）の実装、テストカバレッジの設定、ドキュメントの生成とかね。これがAIの最大の利点だと思う。誰もこれをやりたくないわけじゃなくて、タスクを終える頃には、次のタスクに取り掛かる時間がないからなんだ。マネージャーやスクラムマスターが次のタスクに取り組むように求めてくるから。」

その考え方のポイントは、AIの生産性向上を利用して、最終的な結果がAIの能力と同じことを実装する個人の能力を比較するような機能を追加できるってことだと思う。もう一つの選択肢は、同じ数の機能に取り組んで、それらの機能を自分が知っている限りしっかりと作ることだけど、他にもやるべきことがあって時間がないって感じかな。これはAIの能力と無視する能力を天秤にかけているようなものだね。

それは全く理解できるけど、大きなオープンソースプロジェクト、ましてやNodeや（お願いだから）Linuxカーネルみたいな世界的なものには関係ないよね。そんなもん、さっさと排除しろ。

node.jsの特別なところって何？golang、C#、python、ruby、javaとかには仮想ファイルシステムがあるの？分かるけど、テスト用に実装したこともあるし、これってOSレベルで解決すべきじゃないのかな。--- アップデート もう一つ言い方を変えると、私のコードは実際には、child_process.spawn('something-that-reads-and-write-a-file')なんだけど、また同じ問題に戻ってきた。テストするには仮想ファイルシステムが必要なんだ。Nodeが提供しても助けにはならないよ。

Goには実際にあるよ https://pkg.go.dev/embed 分散型の単一バイナリとしてファイルを配布するのは、スクリプトと比べてちょっと面倒だと思う。後者はファイルのバンドルを考えなきゃいけないからね。でも、確かに存在するよ。