プラグインは公開の入口で提供内容を宣言し、対象のアプリが明示的に組み立てます。依存関係のインストール、実行時の登録、業務への組み込みは、それぞれ別のステップです。
ランタイムごとに独立した登録
| ランタイム | プラグインの入口 | アプリの入口 |
|---|---|---|
| クライアント | package/client | client/plugins.ts |
| サーバー | package/server | server/plugins.ts |
| CLI | package/cli | cli/plugins.ts |
入口は任意です。スキルだけのパッケージには入口がないこともあります。クライアントで登録してもサーバーの入口は有効にならず、サーバーで登録してもページのコンポーネントはインストールされません。
宣言を解決する
defineClientPlugin()、defineServerPlugin()、defineCliPlugin() は提供内容を記述します。アプリはファクトリーをインポートし、その結果を各ランタイムの宣言に加えます。続いてランタイムの解決が、適切な段階でサービスの登録、ルートの組み立て、リソースの読み込み、React の Provider のマウントを行います。
インポート時に業務データを照会したり、タスクを始めたり、接続を開いたりすべきではありません。プラグインのオプションは、固定の組み立ての設定を記述するものです。デプロイの認証情報はサーバーの設定に置き、クライアントのプラグインのオプションには絶対に入れないでください。
依存関係と拡張の境界
ほかのプラグインが公開の入口から利用できるよう、サービスのインターフェースとトークンをエクスポートします。依存関係がない場合は、別のパッケージの非公開のファイルへの相対インポートを求めるのではなく、組み立てや起動の段階ではっきりと失敗すべきです。
クライアントのルートのコンポーネントの上書きは、プラグインが所有するパスと、身元やアクセスのメタデータを保ったまま、ページのローダーを置き換えます。独立して配布される Registry のアセットは編集可能な UI のソースを提供するもので、実行時のプラグインは登録しません。
組み込みを検証する
実際のランタイムでの登録、データベースのリソースの実行、ルートへのアクセス、ビルドしたアプリの動作を確認します。plugin inspect は静的な宣言を読み取るだけで、業務機能を確認するものではありません。登録のスナップショットは宣言されたプラグインを示すもので、実際に使われているすべての機能を示すわけではありません。
プラグインを管理する と UI のソースアセットを公開する を参照してください。