tanatiyo とても初歩的なことなのですが、
すでに2回、失念してしまっていることなので、今後起こさないためにも、戒めのためにここに書いておきます。
ビルドエラーが起こるとデプロイができず、このデプロイの遅延がプロジェクトの進行が遅れることにつながってしまう可能性がある
CI/CDを構築されている環境の場合、ソースコードの変更が行われるたびに自動的にビルド、テスト、静的コード解析を実行するCIパイプラインを構築し、ビルドやテストに合格したコードを自動的にデプロイ（開発、ステージング、本番環境などへ）するCDパイプラインを構築します。
ビルドエラーが発生すると、上記パイプラインでビルドプロセスが中断され、これにより、ビルドされるべき成果物（例えばコンパイルされたバイナリやパッケージ）が生成されない可能性があります。
そしてビルドエラーが解決されない場合、ビルドされた成果物がデプロイされず、アプリケーションの新しい機能や修正がリリースされない可能性があります。これにより、プロジェクトの進行が遅れる可能性があります。
サーバーサイド側の改修のみも重なったときに失念していた
クライアントサイド側の修正だけを行なっているときは、（ブラウザを見ているので）コンパイルエラーが出ていれば気づきやすく、また修正が終わった時点で、ホットリロードからデプロイ用のbuildをして、正常にビルドできるかどうかを確かめることは自然な流れで行うことができていました。
しかし、サーバーサイド側の実装（例えばバッチ処理やユニットテストの実装など）の場合で、コンパイルせずにそのままサーバーサイド側のコード実装だけを行なっていると、ブラウザを見ずにそのままマージリクエストを作成してしまっていた（正常にビルドできるかの確認をしていなかった）ので、クライアントサイド側の改修時も、その流れでホットリロードのみで確認を行い、ビルドを確認せずにマージリクエストを作成してしまっていた。
どう改善するか？
・クライアントサイド側の改修を少しでも行うのであれば、ホットリロードで改修はしていても、必ず最後にビルドを試して、エラーが発生しないかどうか確かめる。
・サーバーサイド側のみの実装時にも、念の為ブラウザ表示をして確かめるようにする（ビルドするのと直接関係はないが、正常に通信が通っているのか、エラーは出ていないか［表示する画面によって事象は違うと思うけれども。。］を、せめてトップのページにアクセスして確認する癖をつけておくと良いのかなと感じた）
→自分の改修したコード箇所だけをみてOKとするのではなく、「自分の改修したコードが原因で」アプリケーション全体に影響を起こしてしまってはいないか（デグっていないのか？）を意識・確認することがとても大事だと学びました。
当たり前にできるように、常日頃気をつけていきたいです。