Design: 提案：ネイティブwasmホストのインポート解決構文

特定の構文を使用する代わりに、wasi実装がlibpreloadスタイルの機能ルールをインポート解像度に適用することをお勧めする場合はどうなりますか？ a.wasmとb.wasmがある場合は、wasiマニフェストで.または./b.wasmを宣言して、 a.wasmからインポートできます。

これにより、wasiは、ブラウザーやノードなど、結合できる他のランダムシステムとの互換性が大幅に向上します。

私はこの提案の一般的な方向性が好きです。 libsが任意にインポートを取得するのを防ぐことが重要のようです。 また、この提案がかなり軽量であることも気に入っています。 ただし、いくつかの考えがあります。

• インポートマップの説明は少し不完全です。 マップエントリa: b/c $で、 $aという名前でb/cをインポートできるという考えはありますか？ もしそうなら、インポートモジュールは名前が（再）マッピングされていることを認識する必要があるため、それがどのようにライブラリのシミングまたは再マッピングを可能にするのかわかりません。 $プレフィックスが必要なのはなぜですか？

• ディレクトリをよりモジュールのように扱うとよいでしょう。各ディレクトリは、周囲に「エクスポート」するファイルを制限することもできます。 このような「エクスポートマップ」は、内向きの環境を定義するインポートマップに追加されます。 エクスポートマップが指定されている場合、モジュールからアクセスできるのは、そこにリストされているファイル/パスのみ、または周囲のディレクトリまたは兄弟ディレクトリのマップをインポート/エクスポートできます。

• 命名メカニズムとして標準のURI参照を使用することに強く同意します。 ただし、 @または$プレフィックスは、相対参照の概念を少し乱用しています（ @a/bはURI用語での相対参照ですが、ここで割り当てられるセマンティクスは非常にrefの絶対的な形式）。

• Bikeshedding：マップのインポートにJSONを使用することには多くのメリットがありますか？ あなたがそれらを説明するとき、それらは単にパスペアのリストで構成されているので、JSONのような複雑で混乱したフォーマットはこれにはやり過ぎかもしれません。

もしそうなら、それがどのようにライブラリのシミングまたは再マッピングを可能にするのかわかりません

私は依存性注入について考えていました。たとえば、2つのモジュールがreactの同じインスタンスを使用する必要があり、 $reactをインポートし、プロジェクトルートに依存してマッピングを提供できます。

しかし、今考えてみると、2つのファイル/モジュールが同じファイル/モジュールをインポートしたときにどうするかという問題が発生します。 2つの別々のインスタンスを作成する必要がありますか、それとも1つの共有インスタンスを作成する必要がありますか？ どちらの回答にもユースケースがあります。

また、デバッグ、リリース、単体テストなどのために複数のwasm_import_mapファイルを作成するメカニズムがあるかもしれないと考えていましたが、それは時期尚早の機能クリープのようです。 Wasmは実際にはCmakeになる必要はありません。

$プレフィックスが必要なのはなぜですか？

これにより、エラーメッセージングがより明確になり、問題の診断がより迅速になります。

Cannot find host module "@foobar"

vs

Cannot find file "some/path/foobar.wasm"

vs

Key "$foobar" not found in imports maps:
- "some/path/wasm_import_map.json"
- "some/wasm_import_map.json"

プレフィックスがないということは、すべての可能性をリストした長いエラーメッセージがあるか、「foobarを解決できません」というCコンパイラと同じ漠然としたインポートエラーが発生し、その理由を推測できることを意味します。

ディレクトリをよりモジュールのように扱うとよいでしょう。各ディレクトリは、周囲に「エクスポート」するファイルを制限することもできます。

エクスポートマップはそれほど有用ではないと思います。 たとえば、「バインディング」サブモジュールと「ネットワーク」サブモジュールをエクスポートするモジュールは、ルートにbindings.wasm ＃$ファイルとnetwork.wasmファイルを含めることができます。

ファイルシステムの安全性のために親ディレクトリからのインポートを制限するメカニズムが必要ですが、子ディレクトリからのインポートを制限する必要はありません（ほとんど制限できません）。

マップのインポートにJSONを使用することには多くの利点がありますか？

あまり。 私もプロトバフについて考えていましたが、実際には、どのフォーマットでも可能です。 1つまたは2つのデフォルト形式が必要です。

私は依存性注入について考えていました。たとえば、2つのモジュールがreactの同じインスタンスを使用する必要があり、$ reactをインポートし、プロジェクトルートに依存してマッピングを提供できます。

命名規則を介して$を介してパラメーターを指定できます。これは、構文上の要件としてそれを焼き付ける必要があることを意味するものではありません。 明らかに、すべての用途がパラメータ化であるとは限りません（一部の混乱した魂が名前を変更したため、「依存性注入」とも呼ばれます:)）。 シミングの場合、システムモジュール（つまり、説明で@で始まる名前）を含む任意のモジュールを再マップできる必要があると思います。

エラーメッセージは解決可能な問題のようです。 特に、説明するシステムは十分に単純であるため、つまり、名前は親dirまたはその中のマップのいずれかでのみ見つけることができます。

エクスポートマップはそれほど有用ではないと思います。 たとえば、「bindings」サブモジュールと「network」サブモジュールをエクスポートするモジュールは、ルートにbindings.wasmファイルとnetwork.wasmファイルを含めることができます。

それは、ネストされたdirのインポートマッピングモジュールによって誰かが意図をオーバーライドするのを防ぐでしょうか？

エラーメッセージは解決可能な問題のようです。

ええ、それらも#includeできますが、失敗したライブラリインクルードのトラブルシューティングは驚くほど難しい場合があります。

いずれにせよ、ユーザーに意図を指定させることには固有の価値があると思います。 これは、ユーザーが何を望んでいるかを明確に理解しているツール設計者にとって成功の落とし穴となります。 また、ユーザーはツールチェーンの仕組みをより簡単に理解できます。

シミングの場合、システムモジュール（つまり、説明の中で@で始まる名前）を含む任意のモジュールを再マップできる必要があると思います。

任意のモジュールに関して、私はそれを避けるために具体的に提案を書きました。 WICGインポートマップで可能な方法でインポートをシムできるようにすると、基になるデザインの堅牢性が低下し、KISSが減少し、多くの名前シャドウイングエラー/エクスプロイトが発生する可能性があります。

（これはWICGインポートマップに対する批判ではありません。私が言ったように、それらはさまざまなユースケースに対応しています）

ほとんどのシミングのユースケースでは、依存性注入のパラメーター化で十分だと思います。より煩わしいシミングの場合は、ツールを使用して、一部のファイルを他のファイルに「手動で」置き換えることができます。

Re：システムモジュール、最も一般的なユースケースは単体テストであるため、それらのシミングはWebAssembly.instantiate APIレベルで行われると考えていました。

構文は常に$とマージできますが、ここでも、意図を表現することに価値があります。

（また、最悪のシナリオでは、@と$を廃止し、オプションの命名規則にします。逆の進行は互換性を損ないます）

それは、ネストされたdirのインポートマッピングモジュールによって誰かが意図をオーバーライドするのを防ぐでしょうか？

いいえ、でもそれが問題かどうかはわかりません。

モジュール作成者の意図を無効にする限り、それはモジュールユーザーの特権です。 モジュールの内部をいじりたい場合は、自己責任で行ってください。とにかくモジュールをフォークすることでそれを行うことができます。

サンドボックスの安全性に関する限り、悪意のあるモジュールが他のプログラムと共有されている外部モジュールをインポートして、不変条件を破る場合（たとえば、 /usr/bin/game_engine/save_progressをインポートする代わりに、悪意のあるコードが/usr/bin/game_engine/save_progress/unsafe_filesystem_functionsをインポートする場合）は問題になる可能性があります。

ただし、おそらくその回避策はありますが、とにかく攻撃ベクトルの可能性はあまりないと思います。

しかし、私が「成功の落とし穴」と「安全なサンドボックス化」アプローチを目指しているのなら、それはocapとWASIのポイントの一種であり、これらも考慮する必要があります。

名前は、親dirsまたはその中のマップのいずれかでのみ見つけることができます。

その中の地図、はい、親のdirs、いいえ。

親ディレクトリ内のファイルにアクセスすると、サンドボックスが機能しなくなり、許可されません。

.wasmファイルは以下にのみアクセスできます：

• ディレクトリ内の.wasmファイル
• サブディレクトリ内の.wasmファイル
• インポートルートまでの親ディレクトリ内のwasm_import_map.jsonファイル

インポートマップ自体は同じルールに従い、サブディレクトリのwasmファイルと親のインポートマップにのみアクセスできます。

ユーザーに意図を指定させることには固有の価値があると思います。

私は非常に同意しますが、この場合、別の意図に関連する有効なユースケースを時期尚早に禁止しているようです。

モジュール作成者の意図を無効にする限り、それはモジュールユーザーの特権です。 モジュールの内部をいじりたい場合は、自己責任で行ってください。

ええ...私は前にその議論を聞いたことがあります;）。 残念ながら、それはゲーム理論が実際に実行される方法ではありません。 そのような意図を明示的に表現し、（ある程度）強制する方法がない場合、何もそれらを止めていないので、誰かがそれをオーバーライドします。 そして、人気のある1人のクライアントだけがそうする必要があり、突然、モジュールライターは、非公式のAPIを保持するか、コードを壊す更新のために推移的な顧客からすべての火を得るのは彼らのすべての負担であることに気付きます。 そこに行って、それをしました。 適切に設計されたシステムが回避に役立つはずの状況です。

ゲーティングインポートの2つは、ゲーティングエクスポートです。 Wasmモジュールは、両方を介した適切なカプセル化を意図的にサポートしています。同じことが1レベル上でも当てはまるはずです。

親ディレクトリ内のファイルにアクセスすると、サンドボックスが機能しなくなり、許可されません。

そうです、私は親ディレクトリのインポートマップのみを意味しました。「または」はずさんな言い回しでした。

そこに行って、それをしました。 適切に設計されたシステムが回避に役立つはずの状況です。

けっこうだ。

私は非常に同意しますが、この場合、別の意図に関連する有効なユースケースを時期尚早に禁止しているようです。

明確にするために、入力されたプレフィックスに関する主な予約は次のとおりです。

• より一般的なシステムで許可される特定のユースケースを防ぐことはできますか？
• または、それらは設計上の制約を表しているため、予期していなかった将来のユースケースを妨げる可能性がありますか？

後者だとは思いませんが、そうだとすれば、私が提案している設計は恣意的ではなく、予期しない将来のユースケースと同じように対処する必要のある問題をカバーしているため、反対する必要があります。

前者の場合、提案を調整できるように具体的な例を考えていますか？ 明らかに、設計したいwasmパッケージエコシステムはまだ存在していませんが、漠然とした「ディレクトリY内にXがあり、Zをシムしたい」というユースケースでも役に立ちます。

明確にするために、プレフィックスを含める理由は次のとおりです。

• ユーザーの意図を明確に伝えます。
• streams.wasmという名前のファイルをインポートし、 streamという名前のパッケージがルートプロジェクトに追加されたためにパッケージが破損するなど、シャドウイングの問題を回避します。
• 既存のパッケージ名を気にせずに、システムライブラリ用に予約された構文を用意します。

WASM / WASIがモジュールの動作をカバーする必要があるかどうか興味があります。 私の最初の考えは、モジュールシステムに関係なく多くの場所で使用できるように、使用すべきではないということです。 wasmtimeがWASMモジュールをロードしてリンクする方法は、ノードがWASMモジュールをロードしてリンクする方法とは大きく異なりますが、理想的には両方とも「正しく機能する」必要があります。

これらの詳細のいくつかについて、Web環境と非Web環境を調整することは可能かどうか疑問に思います。

たとえば、表面的な詳細については、次のようになります@namespace/modulenameを提唱しましたが、Webは組み込みモジュールのnamespace:modulenameに向かっているようです。これは私には問題ないようで、非Web環境も同様です。

より広義には、Wasm / ESM統合提案はJS配管を使用しますが、これは、JSの外部でも同様に意味のあるいくつかのものをエンコードするために行われます。たとえば、相互の関数エクスポートを循環的にインポートする複数のWasmモジュールを使用することはできません（インスタンス化中にエラーが発生しました）。 これらの環境間のセマンティクスをより明確にするために、ESM統合仕様を表現するために作業できるかどうか疑問に思います。

wasmtimeがWASMモジュールをロードしてリンクする方法

現在、wasmtimeはWASMモジュールをまったくリンクしていないと確信しています。 これは文書化された機能ではなく、私のテストでは経験的に機能しません。ソースを見ると、 ResolverインターフェイスはNamespace （ wasi_unstableと一致する）でのみ実装されています。他のハードコードされた名前）およびNullResolver 。

私の最初の考えは、モジュールシステムに関係なく多くの場所で使用できるように、使用すべきではないということです。

しかし、それは実際には実際にはどのように機能するかではありません。 「誰もが自分のニーズに最も適したものを実行できるように、非常に一般的な標準を用意する必要があります」と言うと、「競合する規則や非公式の標準が12あり、どれも問題の領域に正しく対処しておらず、ほとんどのツールは2つまたは3つしか理解できません。そのうちの"。

私は@namespace / modulenameを提唱しましたが、Webは組み込みモジュールのnamespace：modulenameに向かっているようです。

もちろん。 構文はさておき、ファイルシステムのインポートとパラメーター化されたインポートとホストのインポートを区別するというアイデアにもっと興味があります。

より広義には、Wasm / ESM統合提案はJS配管を使用しますが、これは、JSの外部でも同様に意味のあるいくつかのものをエンコードするために行われます。たとえば、相互の関数エクスポートを循環的にインポートする複数のWasmモジュールを使用することはできません（インスタンス化中にエラーが発生しました）。

ええ、これがこの提案が最も欠けている分野だと思います。 リンクセマンティクスをより適切に定義し、esm-integrationリポジトリで問題を作成してオーバーラップについて説明する必要があります。

私が言いたかったのは、インポート構文や解決策などの特定のものを指定することは避けるべきです（ただし、ocapルールなどはかっこいいです）。 wasmを統合したいシステムは、私たちと衝突する可能性のある特定の構文および解決システムをすでに使用している可能性があります。 パスやファイルの概念すら持っていないかもしれません。

簡単なユースケースはありません。 ただし、概念的には、モジュール参照には2種類しかありません。通常は同じコンポーネントの一部である固定の既知のモジュールを参照する確定的なものと、事実上パラメーターであり、モジュールのクライアントによって解決される不確定なものです。 （興味深いことに、Wasm自体には後者しかありません。）

その観点から、第3の種類が何を追加するかは私には完全には明らかではありません。 他の両方の種類をエミュレートできるカスタマイズ可能なオーバーレイメカニズムがあると、どのように役立つかがわかります。 しかし、それは両方の構文形式をとることができる場合にのみ意味があります。 OTOH、他のものをオーバーレイできない場合、パッケージのインポートとは意味的にどのように異なりますか？つまり、 @と$のより深い違いは何ですか？違い？

おそらくあなたの答えは、違いは意図された解決策の語用論にあるということですが、命名規則はおそらく十分でしょう。

さて、私はあなたの質問を今よく理解していると思います。

@と$のより深い違いは何ですか、そしてなぜその違いを配線することが有益なのですか？

私はもっ​​と長い答えを計画していましたが、それを書いているときに、私はその違いの有用性を自分自身で疑問視し始めています。

私の推論は、サンドボックスの安全性のために子ディレクトリのみを指す確定参照が必要であるということですが、親ディレクトリへの確定参照を作成するためのメカニズムも必要です...実際にそうするかどうかはわかりませんか？

私が考えていたユースケースは、主にシミングと代替ビルド（単体テスト、デバッグ、リリース）でしたが、これらをパッケージシステムでベイクする必要はありません。

標準のインポートマップを追加する場合は、誤ってシャドウイングの問題が発生しないように追加する必要があると思いますが、インポートマップがオフラインのインポート解決に役立つかどうかはわかりません。

とにかく、 $構文を削除してマップをインポートすると仮定すると、提案の残りの部分は標準化する価値があると思いますか？

修正された提案は次のようになります。

• オプションのファイルシステムルートオブジェクトをインスタンス化APIに追加します（ WebAssembly.instantiate 、 wasm_instance_new 、 wasm::Instance::make ）

• ツールの規則で、上記のサンドボックスルールを使用して、インポート文字列をURIとして解析するための仕様を追加します。

  • ホストインポートの構文（ @foo/barまたはfoo:barまたはW3Cが決定するもの）を作成します。

潜在的なインポートマップ/エクスポートマップ/シミングメカニズムは後で追加できます。

私もこのようなものの必要性を感じてきました。 ただし、「package」（npmなどのパッケージマネージャーのコードの単位）や「container」など、根本的に新しい、トポロジ的に「より大きな」概念（複数のモジュールを含む）を導入せずに、まだ何も指定できないように感じます。 "（コンテナランタイムで実行できるコードの単位）。これは、上記で指摘したように、パスについて話し合うことができるアンビエントファイルシステムが存在するとは想定できないためです。 「パッケージ」または「コンテナー」の概念（どちらも展開のさまざまなフェーズで意味があると思います）ができたら、解決がどのように機能するかを具体的に説明する方がはるかに簡単です。

また、 @ littledanの目標を共有します。定義されるものはすべて、JS / ESM環境の内外で同じ解釈を持つ必要があります。 そうすれば、ノード内でも外部でも使用できるwasmモジュールの単一パッケージを作成できます。

私は、パッケージまたはコンテナの全体的な概念の必要性を予測して、これらの提案を調整および調整し始める必要があるという強い気持ちを共有しています。 Webを除外するべきではありませんが、 module sandboxもそのままにしておく必要があります。 この提案は、@ lukewagnerと@ jgravelle-googleによるWebIDL提案、@ littledanと@linclarkによるESM統合提案、およびWASI標準の@ sunfishcode @ tschneidereitに関連付けられています。

Webアセンブリモジュール間のリンクとインターフェースの重要な可能性は、次の機能にあると思います。

• シリアル化やIPCを回避できる、実現可能で比較的効率的な方法で、同じスレッド内の異なるプログラミング言語で記述されたモジュールをリンクする
• 信頼できないモジュール（バッファオーバーフローや悪意のあるものなど）にセキュリティの脆弱性が含まれ、モジュールインターフェイスをセキュリティゲートとしてモジュールの外部から適用される明確に定義された（アプリのような）アクセス許可（またはWASI用語ではオブジェクト機能）を備えたモジュールサンドボックス
• ユニバーサルモジュールのエコシステムを構築し、それらを単一のモジュールまたはネイティブの実行可能ファイルにコンパイルする必要なしに簡単に再利用できるようにします。これにより、許容可能なパフォーマンスのトレードオフで、wasmモジュールのnpmインストールを簡単に使用できます。
• 大きなモノリシック「バンドル」の代わりに、より良いロード時間と小さなWebAssemblyモジュールのキャッシングを可能にします（tink、entropic、yarnを使用したnpmなどのパッケージマネージャーは、代わりにグローバルシングルトンインスタンスを使用したファイルベースのハッシュ/キャッシングの方向に進んでいますパッケージ全体を出荷して冗長ファイルをコピーします。また、webpackのようなバンドラーは、http2とのバンドルをスキップする可能性を評価しています。

モジュール内の信頼できないコードを外部から分離するWebassemblyのmodule sandboxは非常にユニークなものであり、バッファオーバーフローや悪意のあるモジュールなどのセキュリティの脆弱性を持つサードパーティのコードを使用するときにセキュリティゲートを導入する可能性があると思います。コミュニティ内でさえ広く見過ごされ、コミュニティのプロファイリングされた専門家から実際には反対の強い主張がありました。

私の懸念は、このモジュールサンドボックス機能の認知度を高め、これらのモジュール間提案を調整して維持しないと、日の目を見る前にこの機能を失い、本質的にプロセスに戻る可能性があることです。サンドボックス。 モジュールサンドボックスからメモリを読み取ることを可能にするサイドチャネルタイミング攻撃があることは知っていますが、少なくとも読み取り専用であり、たとえば、数千のアプリケーションで使用されているjpgデコーダモジュールが侵害された場合、ホームとは呼べない場合でも、被害を制限できます。インターフェイスが画像バッファにのみアクセスでき、ネットワークAPIにアクセスできない場合は、すぐにパスワードを送信します。

正しく行われた場合、Webassemblyは、互換性、セキュリティ、管理など、現在のソフトウェアシステムにおけるいくつかの流行と深刻な問題を解決するのに役立つか、少なくとも封じ込めるのに役立つ、新しいチャイルドセーフ（r）プラグアンドプレイモジュラーエコシステムの始まりになる可能性があります労力（コンテナ）とコードの短い寿命。

ESモジュールのように中央のindex.jsを持つフォルダーは、単一のファイルの上にあるモジュールの次に大きなユニットとして役立つことが証明されているため、このファイルシステムベースのアプローチは実用的であると考えています。それでも、ファイルを相互に依存させたまま、効率的なファイルキャッシングが可能になります。 ただし、モジュールが自身のディレクトリの外にモジュールを直接インポートできないようにする必要があると思います。npmパッケージ名のようなグローバルな一意の参照が解決され、ホストによるセキュリティチェックが必要になります。

これについて何か考えはありますか？

モジュール全体のサンドボックスを維持するのは良いことです。 ただし、モジュールの出所（実装に依存）など、モジュール間の関係に焦点を当てることは避けたいと思います。 たとえば、ファイルシステム内でさえ（そして多くのファイルシステムがあり、それらのすべてがファイルツリーの概念を持っているわけではありません）、これらの機能システムのルール（上向きトラバーサル、下向きトラバーサル、兄弟ファイル、シンボリックリンク、等）。 JSのWebAssembly APIには、wasmの保存場所の概念すらありません。これらは、VMの周りに浮かぶデータの塊にすぎません。

@devsnekファイルシステムやファイルシステムの実装に依存するのではなく、パッケージの階層的包含のより一般的で安全な概念に依存する抽象化であるべきであることに完全に同意します。

階層的封じ込め

互いに素なノードのツリーという意味で、本当に階層的である必要がありますか？ それとも、有向グラフ（つまり「ループのあるツリー」）を意味しましたか？ 「循環依存を装った非循環依存」が必要な状況があります（実際にはそれほど珍しいことではありません）-モジュールM1のAのモジュールM2のBへの依存と同時に、 M2のCの依存M1のDで、モジュールとそのデータに詳細なクエリを実行して、それが実際にサイクルであるかどうかを確認する（簡単/サポート/組み込み/可能）方法はありません。 モジュールレベル（ノードが互いに素なツリー）でのみこのような依存関係を解決すると、そのようなものは不可能になり、開発などが不必要に複雑になります。

@dumblobサブツリー外のインポートの場合：

ただし、モジュールが自身のディレクトリの外にモジュールを直接インポートできないようにする必要があると思います。npmパッケージ名のようなグローバルな一意の参照が解決され、ホストによるセキュリティチェックが必要になります。

再帰的な親子関係は、ホストだけでなく親が子に許可を与える場合に役立つ可能性があると思います。 親は、自分の親から受け継がれた権限のみを付与できます。 これには、サブツリーで定義されていないが親がアクセスできるモジュールをインポートする権限が含まれる場合があります。 また、その中のモジュールを自身の親にエクスポートすることもできます。

与えられた例では、 jpg-decoder Wasmモジュールはsimd-math Wasmモジュールに依存しています。 jpg-decoderは、 [email protected]/simd-math@^1.3.4などのグローバルな一意のパッケージ識別子を使用して依存関係を宣言し、その親からのアクセスを要求します。 親モジュールがこのモジュールにアクセスでき、親によって「子に安全」であると見なされた場合、アクセスが許可され、インポートされたsimd-mathモジュールがjpg-decoderに渡されます。

Re：ファイルシステム

まず、テクノロジースタックとは何かを説明しましょう。

あなたが持っている：

• .wasmバイナリファイル、
• WebAssembly API （C / C ++ / JS）、
• WebAssemblyホスト（手書きのJS、Webpack、WASIインタープリター）、
• ホストの永続ストレージ（通常はファイルシステム）、
• wasmパッケージマネージャー、
• 中央パッケージリポジトリ、
• そのリポジトリにアップロードするためのツール。

したがって、厳密に言えば、wasmバイナリとインスタンス化APIはファイルシステムに対応している必要はありません。 バイナリには標準のインポート構文のみが必要であり、APIには、解析されたインポートURIを渡すことができるコールバックのみが必要です。 例えば：

WebAssembly.instantiateStreaming(
    fetch('someFile.wasm'),
    {
        // ...
        resolveImport: (parsedURI) => { ... }
    }
);

上記の例と同様のAPIを使用すると仮定すると、ホストは理論上、必要に応じてモジュールを保存できます。 たとえば、URIをSQLデータベースへの要求として解釈することにより、ファイルシステム以外のストレージからプルすることができます。

実際には、コミュニティで作成されたコードを再利用したい開発者は、そのデータベースにコミュニティで作成されたモジュールを追加する必要があります。このモジュールは、事実上常にファイルシステム環境で構築されます。

したがって、上記のスタックのホスト部分はファイルシステムに依存しない可能性がありますが、ファイルシステムのようなパッケージ形式、および本質的にツリーのような依存関係システム（独自のサブ依存関係を持つ依存関係）と相互作用する必要があります。独自のサブサブ依存関係。異なるレベル間でパッケージ名が競合することはありません）。

全体として、これはすべて、 @ lukewagnerと@ttraenklerが言ったことに戻ります。インポートスキームを決定する前に、パッケージが何であるか（使用するファイルシステム形式ではない場合）の全体的な定義が必要です。

互いに素なノードのツリーという意味で、本当に階層的である必要がありますか？ それとも、有向グラフ（つまり「ループのあるツリー」）を意味しましたか？ 「循環依存を装った非循環依存」が必要な状況があります（実際にはそれほど珍しいことではありません）-モジュールM1のAのモジュールM2のBへの依存と同時に、M2のCの依存M1のDで、モジュールとそのデータに詳細なクエリを実行して、それが実際にサイクルであるかどうかを確認する（簡単/サポート/組み込み/可能）方法はありません。 モジュールレベル（ノードが互いに素なツリー）でのみこのような依存関係を解決すると、そのようなものは不可能になり、開発などが不必要に複雑になります。

モジュール内サブグラフを契約すると、これらの半循環依存関係は本当に一般的ですか？

各モジュールを単一のノードとして扱う場合、ユースケースの99.9％で、インポートDAGまたはインポートツリーが作成されると思います。

依存関係が単一のパッケージ内で循環的である可能性があると想定するインポート解決スキームがあることは理にかなっていると思いますが、それ以外の場合（npmモデル）は非循環的例外（WASI、ホストライブラリ、ピア依存関係、等）。

さて、この提案を行ったり来たりした後、私はそれの方向性が好きです。 ただし、特定のプレフィックスやその他の種類の「安全」メカニズムを要求する必要はないと思います。 これらは、インタープリターではなく、build-system / pkg-managerによって処理される必要があります。 安全なpkg-managerは、完全な依存関係階層を適切に指定し、それをwasiインタープリターに渡し、wasiインタープリターが指示どおりに解釈できる必要があります。 この関係は次のようになります（半有効なjson）：

[
  {
    "path": "./hash2k3jc/mod/foo.wasi",
    "dependencies": [
      {
        "import": ["mod", "bar"],  # (import "mod" "bar" ...)
        "path": "./hash2k3jc/bar.wasi",
      }
    ]
  },
  {
    "path": "./hash2k3jc/mod/bar.wasi",
    "dependencies": [],
  },
]

ここで、「mod foo」には1つの依存関係（「modbar」）があり、それ自体には依存関係がありません。

これはwasiファイルのフラットリスト（ path ）であり、インポートステートメントを特定のwasiファイルにマップする方法を指定します（ dependenciesとimportおよびpath ） 。

このビルドシステムは、ハッシュを使用して100％明示的かつ安全にすることを選択していることに注意してください。 他のビルドシステム（つまり、クローズド、内部）は、インプレース更新を可能にするために、より緩慢にすることを選択できます。 重要なのは、この表現はどちらのアプローチもサポートできるということです。

IMOは、 https： //webassembly.org/docs/dynamic-linking/を最も厳密に反映しています。wasiファイルやインタープリターに要件をまったく課さず、代わりに最大限の柔軟性とシンプルさを提供することを選択します。

注：wasiインタープリターのファイルシステムを想定するのが適切だと思います。

注：私は「Web用のビルドシステム」ウェイクに取り組んでおり、（最終的には）wasiをプライマリターゲットおよびビルド環境にしたいです。 ライブラリの共有が世界のパッケージングよりも軽量になるように、署名された依存関係を出荷できるようにしたいと思います。

注：wasiインタープリターのファイルシステムを想定するのが適切だと思います。

私は実際にはまったく反対の意見を持っています：ウィンク：。 すでに今日では、ファイルシステムがまったくなく、決して存在しないという深刻なWASMの使用例があります（たとえば、ファイルシステムを持たない新しいまたは実験的なオペレーティングシステムですが、最も基本的な永続ストレージアドレス指定を提供するDBのようなプログラムインターフェイスだけです-最も単純なものですフォームは、ファイルシステムのようなツリーのような構造を必要としない不揮発性RAMハードウェアである可能性があります）。 したがって、ファイルシステムはWASIインタープリターの前提条件であってはなりません（IMHOはユニバーサルWASIパッケージマネージャーでさえファイルシステムのようなストレージを必要とせず、ツリーのようなストレージやブロックストレージまたはキー値よりも線形永続ストレージで動作する必要がありますストレージまたはその他）。

可能性はありますが、すべての依存関係がストレージの単一の連続ブロックにあることを要求したくありません：smile：（ path positionとsizeを使用するなど） path ）。 pathは、DBのようなプログラミングインターフェイスのキーとして使用できますね。 多分それをpath以外の何かと呼ぶべきです... key多分？

パッケージマネージャーの非常に重要な機能として、キーによってバイナリブロブを検索するメカニズムがあると思います：smile：

js仕様では、実際にはモジュールにいかなる種類の指定子も与えていません。 (referringModuleInstance, importString)で解決を実行します。ホストは、そのインポートを許可するかどうか、どこで解決するかなどについて独自の意味を理解する必要があります。Wasmは現在さらに曖昧であり、WASIは次のような追加の制約を課すことができます。 「解決の結果（referringModuleInstance、importString）がインポートするモジュールに推移的にアクセスできない場合は、xyzコードで終了します。」 無駄に、「推移的にアクセス可能」には、おそらくUNIXライクなファイルパーミッションが含まれます。 fastly / cloudflareのようなものにとって、それはおそらく「同じユーザーがアップロードしたアーカイブの一部」を意味します。