以前、プラグイン開発をより速く行うためのローカル環境のセットアップについて質問しました。また、他の人も同様の質問をしていることも知っています。
今回は、非常にうまく機能している新しいワークフローを共有したいと思います。すべてを解決するわけではありませんが、多くの点でより快適になります。以下に詳細を示します。
まず、以前の問題点です。
プラグインを開発するには、ローカルのDiscourseインスタンスからコーディングする必要がありましたが、これは非常に遅かったです。なぜなら、1) ファイルへの変更ごとにページの再読み込みが必要で、Discourseを実行している私のコンピューターでは非常に遅く（ページ再読み込みごとに約30秒）、2) 開発用のローカルDiscourseサイトは非常に遅く（ナビゲーションなどが遅い）、3) バックエンドのプラグインコードへの変更はサーバーの停止と再起動が必要で、数分かかることもありました。その間、私のコンピューターのファンはフル回転していました。
その結果、スムーズなワークフローで通常10分でできるコーディングに、1時間もかかっていた可能性があります。
私の解決策
プラグイン開発とは対照的に、DiscourseテーマCLIのおかげで、テーマコンポーネントのコーディングワークフローは素晴らしいです。（それを使用するための私の手順はここにあります。）高速でスムーズです。
テーマまたはテーマコンポーネントのコーディングが、なぜそれほど速く簡単なのか
テーマCLIツールを使用すると、テーマをローカルでコーディングできますが、「監視」できます（つまり、テーマを実行します）。これは、実際のサイト、実際のサイトのプレビューモード、またはセットアップしたテスト用のライブサイトで行います。
そのため、Discourse自体をマシンで実行する必要はありません。したがって、プラグインの場合のようにマシンが遅くなることはありません。変更を加えるたびに、リンクしているライブサイトを更新するだけで、変更が反映されます。
そこで気づいたのは、プラグインをコーディングする時間のほとんどは、実際にはフロントエンドの（hbsファイル、javascriptファイルなど）コーディングに費やされているということです。バックエンドの（ルートの設定、カスタムフィールドの作成など）コーディングに費やされる時間はごくわずかです。
そのため、すべてを一緒にコーディングするのではなく、フロントエンドのコーディングはすべてテーマコンポーネントに移動して、テーマコンポーネントのワークフローを活用します。
バックエンドの更新が必要になった場合は、再びプラグインでコーディングする必要があります。しかし、それは時間の約20％にすぎません（私のプラグイン開発では）。これにより、より快適なテーマコンポーネントのワークフローで時間の80％を費やすことができるようになりました。
本番環境にすべてを移行する時期が来たら、次のことができます。
-テーマコンポーネントとプラグインを別々に保ち、関連するDiscourseサイトで使用するだけです。または、
-すべてのコードを1か所にまとめることが重要な場合は、テーマコンポーネントのコードをプラグインに移動します。確かに少し手間がかかるかもしれませんが、本番環境への更新準備ができたときにのみ行う必要があり、その間もより高速なテーマコンポーネントのワークフローを楽しむことができます。
以上です。
革命的ではありません。しかし、しばらくの間私を悩ませていた問題を大幅に改善してくれました。