ハハ、言った通り、別の用途に使っているので、ただ殺すわけにはいきません。ポートを変更するのは、そんなに難しくないはずですよね（有名な最後の言葉のようです）。
「いいね！」 1
リンク先のトピックで質問することをお勧めします。スクリプトをざっと見たところ、ハードコーディングされているように見えましたが、間違っている可能性もあります。スクリプトはビルドされている可能性があります。
ハードコードされたものにも気づきましたが、YAML ファイル内のポート構成や環境変数への参照もあります。現時点ではこれで諦めます。テストしたかったことに対して、すでに投資した時間が長すぎます。
Ubuntu 22.04 のクリーンな VM を起動しました。開発者向けインストールが失敗します: Install Discourse for development using Docker - #213 by nordize
今日はついていない…でも、間違いなく数分では済まない（言葉遊びではありません）。お時間をいただきありがとうございます。無駄にしてしまって申し訳ありません。
「いいね！」 1
@merefield 早速の質問です。コンテナ内でプラグインコードのアップデートを、時間がかかり、Dockerイメージをプルする際に大量のデータをダウンロードするd/shutdown_dev; d/boot_devよりも速く行う方法はありますか？ブラウザでテストするためにコードを1行変更するたびにこれを行うのは、Docker化された環境であっても過剰に思えます。
d/rails sでRailsサーバーを再起動しても、プラグインのコード変更は反映されません。
これは、コード行を変更した場合ではなく、プラグインを削除または追加した場合にのみ必要になります。
それがRubyまたはCSSの行であれば、新しいコードはホットロードされます。Rubyの場合は、ターミナルでユニコーンが再起動するのを確認できるはずです。
それがJavaScriptの場合は、ブラウザをリフレッシュするだけで済みます。
プラグインがシンボリックリンクにあり、d/shutdown_dev; d/boot_dev を実行しないと変更が反映されないことを言及するのを忘れていました（これはガイドにも記載されています）が、これらは単にマッピングされたファイルであるはずなので、Docker自体で回避策がないかと思っていました。他のスレッドで質問するか、回避策として変更できるか（またはシンボリックリンクを使用しないか）を確認します。
これは私には正しく聞こえません。サーバープロセスは、Docker以外のインストールで実行されるのと同様に単純に再起動します。シンボリックリンクは違いを生むべきではなく、適切な方法です。なぜあなたのものがそのように動作しないのか全く分かりません…
まあ、お気軽に試してみてください。RailsとEmberの再起動だけで済むなら、投稿しませんでした。言ったように、ガイドにもこの点が指摘されています。
ガイドによると、これらの再起動コマンドは、プラグインの構成を変更した場合（有効なシンボリックリンクの削除または追加など）にのみ必要になるはずです。それ以外の場合は、Rails がコードの変更を検出し、プロセスを再起動する必要があります。設定でこの動作を無効にできる可能性はありますが、それはデフォルトであるはずです。
これは自動再起動の例ですが、Docker を使用しない開発環境でのものですが、動作は同様のはずです。
[DEV]: 自動ロードされないファイルを編集しました。サーバーを再起動しています...
- plugins/discourse-multilingual/extensions/post.rb
UNICORN を再起動しています
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228047 exit 0\u003e worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228048 exit 0\u003e worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228049 exit 0\u003e worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Gem リストをリフレッシュしています
TERM シグナルを受信しました
シャットダウン中
静かなスレッドを終了しています
スケジューラ終了中...
ジョブ完了まで一時停止しています...
さようなら！
CSS 変更ウォッチャーを開始しています
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
post.rb ファイルを編集して保存したところ、残りは自動で行われました。
現在、Docker ベースの開発マシンにアクセスできないため、Docker インストールでも同様かどうかを確認できません。申し訳ありませんが、変更がなければそうだったと記憶しています。
作り話ではありませんよ 
そして、動作するはずだと言われても、あまりできることがありません Ubuntu 22.04 の新しい VM インストールで、そのガイドを文字通り実行しました。
- プラグインを discourse/plugins/ サブフォルダにシンボリックリンクし、プラグイン内の JS コードを変更しても、d/shutdown_dev; d/boot_dev を実行しない限り 表示されません。d/rails s と d/ember-cli を再起動してもダメです。
- プラグインを discourse/plugins/ サブフォルダにコピーし、プラグイン内の JS コードを変更すると、d/shutdown_dev; d/boot_dev を実行しなくても表示されます。d/rails s と d/ember-cli を再起動するだけで済みます。
上記を試してみてください。問題のプラグインは discourse-math です。assets/initializers/javascript/\*.js のコードを変更しています（これらの特定のプラグインファイルはサイドロードされており、ブラウザから直接 GET 呼び出しされるわけではないことに注意してください。Discourse が内部でどのように機能するかについては、まだ深く掘り下げていないので、それが違いを生むかどうかはわかりません）。
追伸 ブラウザをリフレッシュする必要があることはわかっています（キャッシュをバイパスして）… 少しは信用してください。
まさに当事者から、以下のURLを参照してください。
したがって、問題はローカル環境に起因しているか、現在のビルドでのリグレッションの可能性がありますが、後者の可能性は低いと思われます。
もう降参だ、君の勝ちだ。もし自分で試すことがあったら教えてくれ。
「勝つ」ことを目指しているわけではありませんが、まずは理解の基盤を築く必要があります。
- バックエンドのコード変更時に自動再起動するはずです。
d/shutdown_dev; d/boot_devは、プラグインの個々の行ではなく、プラグインの構成を変更した場合にのみ必要になるはずです。
これにより、修正が必要な箇所を絞り込むことができます。
git pull して変更を試しましたが、再起動しました。ビルドの回帰ではありません。
さらに奇妙なのは、Docker セットアップであるため、パッケージ化された動作を意図せず上書きすることは実際にはより困難であり、より信頼性が高くなるはずです。
家に帰ったら、Docker ビルドでこれを試してみます。
現在のワークフローとして、これがフラストレーションや煩わしさを引き起こしていることは理解しており、私自身も同様にフラストレーションや煩わしさを感じるでしょう。
キャッシュを完全にクリアした場合、現段階で他に提案できることはわかりません。
イニシャライザーは、ページを初めて開いたときに一度だけ実行されることに注意してください。したがって、サーバープロセスの再起動は無意味であり（バックエンドコードのみをカバーします）。
Webアプリを開発する際は、常にキャッシュを無効にして開発ツールを実行しています。Discourseのコードとツールには慣れていませんが、(Web)開発自体には慣れています。ガイドのスレッドにも質問を投稿しました。今のところ、面倒を避けるために、discourse/plugins/の下のプラグインディレクトリをコピーしただけです。
「いいね！」 1
後で同様のことを試して、結果を報告します。
ブラウザの呼び出しから見る限り、初期化JSからのJSコードは eval() (ページを開くたびに) を介して discourse-math.js からサイドロードされています。これは明らかに、何らかのサーバーサイドコンポーネントが初期化JS (私が変更しているもの) からそのJSコードを処理およびキャッシュしており、したがって、再キャッシュするようにトリガーする必要があるのは その 特定のサーバーサイドキャッシュであり、プラグインがシンボリックリンクされている場合は発生しませんが、コピーされている場合は発生します。
私は Discourse のツールチェーンに精通していません (時間不足のため、現時点では精通したいとも思いませんでした) … それゆえ、私のリバースエンジニアリングと質問です。
「いいね！」 1
non-docker dev:
これをイニシャライザーで試しましたが、プロセスを再起動する必要はなく、ブラウザをリフレッシュするだけでJSコードの変更が反映されました…これは非Docker環境での話です…後で試してみます。
しばらくして…
docker-dev:
PCに戻ってDockerソリューションを試しました。完全にクリーンインストールしましたが、同じ動作が見られます。イニシャライザーの編集は、サーバーを実行したままファイルを保存してブラウザをリフレッシュするだけで機能し、コンテナの再構築は不要です。
つまり、同じ動作です。
（例としてDiscourse Locationsプラグインを使用しました。）
イニシャライザーに何か問題があるのではないでしょうか？
再起動後に動作することから、はい、確認しました。100%確実に再現するには、私が言及した特定のプラグインを試して、GUIで有効にし、GUIでKatexオプションを選択してから、私が言及したイニシャライザーJSファイルを編集し、次にLatexコードを含む投稿を作成してみてください。このプラグインは特別で、投稿にLatexコードが含まれている場合にのみJSイニシャライザーをオンザフライでロードする可能性があります（Discourseを設計するなら私がそうします）…しかし、この問題に時間を無駄にすることを期待していませんし、私が作り話をしていないことを説得しようとしているわけでもありません
「いいね！」 1
はい、良い点ですね。
それは非常に非常に奇妙です。
現時点での唯一の提案は、Docker以外のインストールに切り替えること（残念ながらセットアップに時間がかかります 
）で、それがどのように機能するかを確認することです。
何がうまくいかないのか、チームからいくつか意見を聞けると良いのですが。しかし、Dockerソリューションは、コンテナ化され、アトミックであるため、ここでは異なる動作の可能性を確実に減らすはずです 