ブロック開発におけるnpmとcomposerの活用方法

npmの基本的な使用方法については、他のブログに譲ります。
ここでは、１目のプラグインを@wordpress/create-blockでプロジェクト生成してから、どのようにして２つ目のプラグインのプロジェクトを生成していくかということに焦点を絞ります。
npx @wordpress/create-blockプロジェクトを生成すると、そこにはWeb Packによるトランスパイル環境が整います。それで基本的なnpmの利用環境が整うといっていいと思います。
我々開発者はその環境が整ったうえでedit.jsやsave.jsといったJavaScriptファイルを加工していくのですが、複数のプラグインを作成するとすれば、その度にnpx @wordpress/create-blockを実行して別々の開発環境を作ってきました。
そして、複数のプラグインで共通に利用したいモジュールはnpmパッケージにまとめ、それぞれインストールしていました。
しかし、これだとnpmパッケージをバージョンアップする度に、すべてのプラグインでnpm installを実行しなければなりません。npmパッケージが１つならまだいいですが、複数になると手間が大変です。そもそも、他に依存しているnpmパッケージもあるはずで、@wordpress/scriptsという依存関係にかかわる根幹のパッケージは必ず使っているはずです。このパッケージもバージョンアップしているんです。
これを何とかする方法はないかと色々調べました。そもそも、モジュールはプラグイン内のimport文でインポートします。自分で作ったモジュールをimportするときは、そのモジュールが含まれるjsファイルのパスを指定するのですが、npm installでインストールしたパッケージにはパスがありません。
まったく基本的な話でしょうが、パッケージ名にパスがない場合はnode_modulesフォルダ内を探しにいくのです。
では、このnode_modulesフォルダはどこのフォルダ内のnode_modulesフォルダでしょうか？
Claude３が回答をくれました

edit.jsファイル内でimport { useBlockProps } from ‘@wordpress/block-editor’;と記述した場合、ビルドプロセスは以下の手順でuseBlockPropsモジュールを探します。

1. まず、プラグインフォルダ（/my-project/plugins/my-plugin/）内のnode_modulesフォルダを探します。
2. プラグインフォルダ内にnode_modulesフォルダが見つからない場合、ビルドプロセスは親ディレクトリを順番に遡ります。この例では、プロジェクトのルートディレクトリ（/my-project/）まで遡ります。
3. プロジェクトのルートディレクトリにあるnode_modulesフォルダ内で@wordpress/block-editorパッケージを探します。
4. パッケージが見つかったら、そのパッケージ内でuseBlockPropsモジュールを探します。
5. モジュールが見つかったら、そのコードを含むファイルを特定し、バンドルプロセスに含めます。

そうすると複数のプラグインで共通のnpmパッケージを利用したいのであれば、wp-contentフォルダにnode_modulesをつくり、そこでnpmインストールでパッケージをインストールすれば、それぞれのプラグインは共通の上位フォルダであるwp-contentフォルダのnode_modulesを見に行ってくれるということになります。
具体的にはwp-contentフォルダに移動して、ターミナルから

npm install @wordpress/scripts

を実行します。そうすると、wp-contentフォルダ内にpackage.jsonが生成されるとともに、node_modulesフォルダも生成され、そこにブロック作成に必要なモジュールが詰め込まれます。
さらに、すべてのプラグインで使用するnpmパッケージをnpm installでインストールすれば、そのモジュールも、wp-contentフォルダ内のnode_modulesフォルダに格納されます。
そうしておけば、各プラグインでは共通のnpmパッケージをインストールする必要はないのです。