12
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@septigram

VSCodeでフロントエンドとバックエンドを並行開発するためのレポジトリ構成

12
Posted at

VSCodeでフロントエンドとバックエンドを並行開発するためのレポジトリ構成

概要

VSCodeを用いてフロントエンド（Vueなど）とバックエンド（Spring Bootなど）を同一プロジェクト内で並行開発する際の、レポジトリとワークスペースの構成案です。

単一のモノレポを前提にしつつ、フロント用とバックエンド用でVSCodeのプロファイルと表示対象を分け、拡張機能の干渉を避けながら開発するための具体的な手順を整理します。

背景

フロントエンドとバックエンドを同じVSCodeウィンドウで扱う場合、次のような問題が発生することがあります。

  • フロントエンド向けの拡張機能が、バックエンドのソースにも反応し、補完・リンター・フォーマットが意図しない挙動をする
  • プロジェクトツリーに両方のディレクトリが並ぶため、フォーカスが分散する
  • フロントエンドのビルド成果物をバックエンドの静的配信先に毎回手作業でコピーする手間が発生する

一方で、VSCodeには「1つのフォルダ（ワークスペースルート）に紐づけられるプロファイルは1つ」という制約があります。

この制約の下で、モノレポを維持したまま、フロントエンド用とバックエンド用で見た目と拡張機能を分離する方法を検討しました。

要件と制約

要件

本構成で満たしたい要件は次のとおりです。

項目 内容
開発環境 VSCodeでフロントエンドとバックエンドを同時に扱えること
共有リソース ドキュメントおよびAPI定義（Protocol Buffers、OpenAPIなど）を共通で参照・編集できること
プロファイル分離 フロントエンド用とバックエンド用で、VSCodeのプロファイル（拡張機能セット）を分けられること
レポジトリ 1プロジェクト1モノレポとすること
表示の制御 フロント用ワークスペースではバックエンド配下を、バックエンド用ワークスペースではフロントエンド配下を、エクスプローラーおよび検索対象から外せること
ビルド成果物 VSCodeの操作に依存せず、フロントエンドのビルド結果をバックエンドの所定ディレクトリへ自動配置できること

制約

  • VSCodeにおいて、同一のフォルダに割り当てられるプロファイルは1つです。
    そのため、「1つのフォルダを開いたまま、フロント用とバックエンド用で別プロファイルを切替える」ことはできません。

解決方針

上記の要件・制約を満たすため、次の方針をとります。

  1. 1本のベアレポジトリを用意し、その中に doc / frontend / backend をサブディレクトリとして配置する
  2. 開発用のクローンを2つ用意する
    一方はフロントエンド開発用（project-frontend）、もう一方はバックエンド開発用（project-backend）として運用する
  3. 各クローンのルートをワークスペースとして開き、フロント用クローンにはフロント用プロファイル、バックエンド用クローンにはバックエンド用プロファイルを割り当てる
  4. 各クローン内の .vscode/settings.json で files.exclude と search.exclude を設定し、不要なディレクトリをエクスプローラーおよび検索から除外する
  5. フロントエンドのビルド後、**ビルドスクリプト（postbuild など）**でバックエンドの静的リソース用ディレクトリへ成果物をコピーする

このように「ベアレポ + 用途別クローン + ワークスペース設定 + postbuild」を組み合わせることで、モノレポを保ちつつ、見た目と拡張機能のコンテキストを分離できます。

git1.png

構成の詳細

リポジトリとディレクトリ構成

ベアレポジトリは、通常の git clone --bare で用意します。
そこで管理するモノレポのツリーは次のとおりです。

doc/         # ドキュメント、API定義（Protocol Buffers、OpenAPI など）
frontend/    # フロントエンド（Vue など）
backend/     # バックエンド（Spring Boot など）

開発用クローンは、上記ベアレポジトリから通常の git clone で2つ作成します。

project-frontend/    # フロントエンド開発用ワークスペース
├── .git/
├── doc/
├── frontend/
└── backend/         # files.exclude で非表示

project-backend/     # バックエンド開発用ワークスペース
├── .git/
├── doc/
├── frontend/        # files.exclude で非表示
└── backend/

両方のクローンに doc / frontend / backend が含まれるため、ドキュメントやAPI定義はどちらのワークスペースからでも編集・コミットできます。

ワークスペース設定（.vscode/settings.json）

設定は各クローンのルートにある .vscode/settings.json（ワークスペース設定）に記述します。

  • プロファイルは、VSCodeで「フォルダを開く」ときに選んだフォルダに紐づきます
    そのため、project-frontend を開くときはフロント用プロファイル、project-backend を開くときはバックエンド用プロファイルをあらかじめ割り当てておきます
  • files.exclude と search.exclude は、開いているワークスペースのルートからの相対パスで指定します

フロントエンド用クローン（project-frontend/.vscode/settings.json）の例:

{
  "files.exclude": {
    "backend": true
  },
  "search.exclude": {
    "backend": true
  }
}

バックエンド用クローン（project-backend/.vscode/settings.json）の例:

{
  "files.exclude": {
    "frontend": true
  },
  "search.exclude": {
    "frontend": true
  }
}

ビルド成果物の配置

フロントエンドのビルド出力を、VSCodeに頼らずバックエンドの所定ディレクトリへ配置します。

方法A: postbuild でコピーする（推奨）

バックエンドの静的リソースが backend/src/main/resources/static に置かれる構成の場合、フロントエンドの package.json で postbuild を定義します。

frontend/package.json の例:

{
  "scripts": {
    "build": "vue-cli-service build",
    "postbuild": "node -e \"require('fs').cpSync('dist', '../backend/src/main/resources/static', {recursive:true})\""
  }
}

fs.cpSync は Node.js 16.7 以降で利用できます。
Windows を含め、npm run build や yarn build の実行カレントが frontend であれば、上記の相対パスでバックエンド側にコピーされます。
OSごとに挙動を変えたい場合は、次の方法Bのように専用スクリプトに切り出すとよいでしょう。

方法B: 専用スクリプトを用意する

frontend/scripts/copy-to-backend.js などのスクリプトを用意し、package.json の "postbuild": "node scripts/copy-to-backend.js" から呼び出します。
コピー先パスや上書きルールをスクリプト内にまとめると、環境差分の管理がしやすくなります。

Git の運用

  • 共有の起点はベアレポジトリ1本です
    project-frontend と project-backend は、いずれもそのベアレポジトリを remote にした通常のクローンとして push / pull します
  • 作業パターンの例:
    • フロントエンドのみ変更するとき: project-frontend で編集・コミット・必要に応じて push
    • バックエンドのみ変更するとき: project-backend で編集・コミット・必要に応じて push
    • 両方を変更するとき: いずれか一方のクローンでまとめて変更するか、両方で変更してからどちらかで pull → merge で取り込みます
  • コンフリクトは、そのクローン上で解消したうえでコミット・push します
  • ブランチ戦略（main / develop の使い分け、feature ブランチの有無など）は、チームのルールに合わせて決めます

運用フロー

初回セットアップ

  1. ベアレポジトリを作成し、doc / frontend / backend を配置して push します
  2. フロントエンド用・バックエンド用の2つのクローンを、上記の構成で作成します
  3. 各クローンのルートに .vscode/settings.json を、上記の内容に従って配置します
  4. VSCodeで project-frontend を「フォルダで開く」し、このフォルダにフロント用プロファイルを割り当てます
  5. 同様に project-backend を開き、バックエンド用プロファイルを割り当てます

日々の開発

  • フロントエンドのみ触る日は project-frontend を開き、バックエンドのみ触る日は project-backend を開きます
  • ドキュメントやAPI定義の更新は、どちらのクローンから行ってもよいです
  • フロントエンドのビルドをバックエンドに反映するときは、フロント用クローンで yarn build（または npm run build）を実行し、postbuild によりバックエンドの静的リソース用ディレクトリへコピーされることを確認します
    その後、バックエンドを起動して静的ファイルの配信を確認します

参考：他方式との比較

本要件を満たすにあたり、以下の方式も検討しました。
いずれも「プロファイルの完全な分離」または「運用の単純さ」の点で、本稿の方式に劣るため、採用していません。

方式 内容 主な制約
Multi-root Workspace（.code-workspace） 1つのワークスペースファイルで複数フォルダをまとめて開く ウィンドウ単位でプロファイルが1つのため、フロント用・バックエンド用で拡張機能を完全に分けられない
Extension profiles 拡張機能 ワークスペースに応じて拡張セットを切り替える 起動中の全ウィンドウで同じプロファイルが適用されるため、「フロント用ウィンドウとバックエンド用ウィンドウで別プロファイル」にできない
シンボリックリンクで frontend/backend だけを別ツリーに配置 実体は1クローンとし、作業用ディレクトリだけシンボリックリンクで分ける doc の共有方法や、リンク先から見た .git の位置の扱いが煩雑になりやすく、運用が分かりにくい

以上の理由から、本稿では「ベアレポ + 用途別クローン + ワークスペース設定 + postbuild」の組み合わせを採用しています。

まとめ

VSCodeの「1フォルダ1プロファイル」という制約の下で、モノレポを維持しつつフロントエンドとバックエンドの開発コンテキストを分けるには、同一ベアレポジトリから、用途別に2つのクローンを用意し、それぞれを別ワークスペース・別プロファイルで開く構成が有効です。

本稿で示した設定と運用フローを踏まえれば、拡張機能の干渉を抑えながら、ドキュメントとAPI定義の共有、およびビルド成果物の自動配置を一連のやり方で扱えます。

12
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?