NocoBase では、プラグインは機能を独立してパッケージ化し、アプリが必要に応じて組み込めるようにするものです。プラグインを書く主な理由は 2 つあります。コードの再利用とコードのモジュール化です。どちらか一方でも、プラグインを選ぶ理由になります。
1. コードの再利用
複数のアプリが同じ機能を必要とする場合は、各アプリで実装したりコピーしたりするのではなく、共通の部分をプラグインとしてパッケージ化します。
たとえば、複数の業務アプリが同じ SMS のプロバイダーを使うとします。プラグインがメッセージの配信、プロバイダーの設定、エラーを扱い、各アプリはそれをインストールして使います。注文のアプリは注文の通知をいつ送るかを、承認のアプリはリマインダーをいつ送るかを決めます。どちらも、基盤となる SMS の実装を共有します。
修正や改善は 1 か所で保守でき、各アプリは適切なタイミングでアップグレードします。プラグインは安定した公開のインターフェースを提供し、アプリは自身の業務の組み立てと設定を担います。
共通の機能を実装する前に、既存のプラグインが要件を満たすかどうかを確認してください。プラグインを管理する を参照してください。利用できる機能が合わない場合に、独自の実装を開発します。
2. コードのモジュール化
プラグインは、1 つのアプリの中でコードを整理するためにも使えます。関連するページ、エンドポイント、サービス、データのロジックを 1 つのモジュールにまとめると、機能の境界が明確になり、インストール、設定、保守、アップグレードが簡単になります。
たとえば、アプリに注文、在庫、レポートの機能があるとします。機能が大きくなったら、それぞれを別のプラグインに整理できます。
my-app/
├── client/ # アプリの UI の組み立てと入口
├── server/ # アプリのサービスの組み立てと入口
├── packages/
│ ├── app-plugin-orders/ # 注文のモジュール
│ ├── app-plugin-inventory/ # 在庫のモジュール
│ └── app-plugin-reports/ # レポートのモジュール
├── package.json
└── pnpm-workspace.yaml各プラグインは、それぞれの実装、公開の入口、設定、テストを保守できます。どのプラグインを組み込み、どう組み立てるかはアプリが決めます。チームのメンバーもモジュールごとに作業でき、ほかの機能の内部実装に頼る必要が減ります。
モジュール同士が依存することもあります。たとえば、レポートのプラグインは、注文のプラグインの非公開のソースファイルをインポートするのではなく、明示的な公開のインターフェースを通じて注文のデータを取得します。これらの機能をプラグインとして整理すると、関係が明確になり、保守しやすくなります。
アプリの中でプラグインを開発する
まず create-app でアプリを作成 し、その中でプラグインを開発します。アプリはモノレポに対応しています。ローカルのプラグインは packages/ の下に置き、pnpm workspace の依存関係でつなぎ、アプリと一緒に開発、ビルドします。
プラグインは、npm に公開せずに現在のアプリだけで使うこともできます。 ほかのアプリでも必要になったら、配布、バージョン管理、互換性を検討します。再利用とモジュール化は並行して進められます。まず現在のアプリの機能をプラグインとして整理し、成熟したらほかのアプリと共有します。
プラグインの大きさは機能によって決まります。CLI のコマンドを 1 つ提供するだけのこともあれば、Client のページ、Server のエンドポイント、データベースのロジックを含むこともあります。すべての機能を持つ必要はありません。ディレクトリと入口については プラグインの構成 を参照してください。
適切な整理の方法を選ぶ
プラグインは機能を整理する方法の 1 つです。単純なページや業務ロジックは、アプリに直接置けます。インポートでだけ再利用する関数、型、ユーティリティーは、通常のモジュールや共有のパッケージにできます。機能をひとまとまりとして組み込み、保守したい場合や、複数のアプリで使えるようにしたい場合に、プラグインを検討してください。
続いて プラグインを作成する で、@nocobase/create-plugin を使ってひな形を生成します。プラグインの構成 を理解したら、最初のプラグインを書く に従って、実装、登録、検証を行います。
バージョンを独立して管理しながら複数のアプリで共有するには、ビルドと公開 に進んでください。現在のアプリだけでプラグインを使う場合、公開は不要です。