vscodeの環境はプロジェクトごとがいいよね？【備忘録】

はじめに

ぼくはVSCodeを使っている。
そしてプラグインをよく入れたりするし、設定もよく変える。
だが、このプロジェクトにはいるけど他のプロジェクトには入らないプラグインや設定ってあるよな。
つまり

どのプロジェクトにも共通して使いたいプラグインと設定
特定のプロジェクトしか使いたくないプラグインと設定

を分けたいんです。

調査

しらべてき。

参考サイト

www.mitsue.co.jp

→ 何をgithubに上げて、何を禁止するか書いてある。

qiita.com

→ そもそものやり方。setting.jsonの分け方教えてくれる。

maku.blog

→ お作法を教えてくれる。

amateur-engineer-blog.com

→ 言語ごとに設定変えれるの？驚き。

code.visualstudio.com

→ 公式。いっちゃん助かった。やっぱり一次情報。

考察

てかこれって、マイクロサービスだった場合、serviceごとがいいのかな？projectごとがいいのかな？どっちもできそうではある。

これ3階層じゃないかな？

ローカル環境依存の設定
プロジェクト依存の設定
サービス依存の設定

だとするとこれ全部分けてみようか。ここまでやる必要あるか？とも思うが、単一責務だとも思う。

(...数時間後)

こんな文が公式から出てきた。

Note: A VS Code "workspace" is usually just your project root folder. Workspace settings as well as debugging and task configurations are stored at the root in a .vscode folder. You can also have more than one root folder in a VS Code workspace through a feature called Multi-root workspaces. You can learn more in the What is a VS Code "workspace"? article.

公式に「こう思うよね？w」って言われてるようで腹たつ。まぁみてみよう。

code.visualstudio.com

みたけども、ちょっとだけ意図とは違った。以下のようなことができる。

同じVSCodeのwindowでいろんな階層をrootとして開けるんだと。そうすると、それぞれの階層ごとのsetting.jsonは競合しちゃうんだけど、それをworkspace.jsonという形でプロジェクト依存のsetting.jsonみたいに修正できる。かつそれを保存できるから永続化も可能。

だーーけーーどーー、そもそもdockerでserviceを開いた時にこのworkspace.jsonを開けないんじゃ意味ないやん。

つぎここから

Visual Studio Code User and Workspace Settings

だけど、みてみるとこれが書いてあった

構成は、異なる設定スコープによって複数のレベルで上書きできます。次のリストでは, 後期のスコープは以前のスコープをオーバーライド:

デフォルト設定-このスコープは、構成されていないデフォルトの設定値を表します。

ユーザー設定-すべてのVSコードインスタンスにグローバルに適用します。

リモート設定-ユーザーが開いたリモートマシンに適用します。

ワークスペース設定-開いているフォルダまたはワークスペースに適用します。

ワークスペースフォルダーの設定-の特定のフォルダーに適用マルチルートワークスペース。
引用元：Visual Studio Code User and Workspace Settings

リモート設定ができるっぽい？もうちょい調べてみよう。

お、こういうこと

Developing inside a Container using Visual Studio Code Remote Development

だけど、こんなに強制力を持たせなくてもいいかな。

と、ここまで調べてみて、結論がでた。まず、階層は3つでよい。

ローカル環境依存の設定
プロジェクト依存の設定
サービス依存の設定

だけど、2と3は1の環境を引き継ぐけど、3は2の環境を引き継がなくてもいい気がする。なぜならそのような状態が必要なことはほぼないし、あったとしても2と3の環境にそれぞれ設定を記述するで対応をすれば良いと思う。

また、DevContainerという拡張機能でサービスごとの開発環境を開くのだが、その時に2で適用している拡張機能は3の時にレコメンド表示してくれるため、2の環境の一部を3に引き継ぎたい時も容易かと思われる。

方針結論

以下の3段階にvscodeの設定を変えていく。

ローカル環境依存の設定
プロジェクト依存の設定
サービス依存の設定

だが、3の環境は2の環境を拡張するような設定ではなく、あくまで2と3は独立しているものとする。

やってき

まぁ簡単な話、分けるだけ。階層構造は以下。

ローカル(ユーザー)依存の設定：~/Library/Application Support/Code/User/settings.json
プロジェクト依存の設定：プロジェクトフォルダのrootに.vscode/を用意して設定
サービス依存の設定：サービスごとのworking_dirのrootに.vscode/を用意して設定

じゃあ試しに自分のやつを公開します。

1. ユーザー依存の設定

以下が設定ファイルそれぞれの言語に依存していた設定はそれぞれのサービスに移動させている。

{
  "editor.accessibilitySupport": "off",
  "editor.tabSize": 2,
  "emmet.triggerExpansionOnTab": true,
  "security.workspace.trust.untrustedFiles": "open",
  "editor.formatOnSave": true,
  "codic.ACCESS_TOKEN": "mU2hEdPGcRbrWeRGk9sDH5aQl1OBjmlvxv",
  "codic.case": "snake_case",
  "explorer.confirmDelete": false,
  "terminal.integrated.scrollback": 10000,
  "editor.fontFamily": "Menlo, Monaco, 'Courier New', monospace, 'MesloLGS NF'",
  "git.autofetch": true,
}

拡張機能はどのプロジェクトでも使うであろうものにした。

2. プロジェクト依存の設定

setting.json に関してはなかった。プロジェクト固有で持ちたい設定もなかったし、他の開発者に強制したいような設定もなかった。

拡張機能に関しては、他の開発者に強制したいものがあったので、設定。 dockerとDev Containersの2つ。

{
  "recommendations": [
    "ms-vscode-remote.remote-containers",
    "ms-azuretools.vscode-docker"
  ]
}

3. サービス依存の設定

大きく分けて、フロントエンドとバックエンドに分けた。今回だったらクライアントはTypescriptで記述しており、バックエンドはGolangで記述している。

フロント

linterとprettierの設定。

{
  "editor.defaultFormatter": "esbenp.prettier-vscode", //デフォルトのフォーマットはprettierを指定
  "editor.formatOnSave": true, //保存したときにフォーマットする
  "editor.codeActionsOnSave": {
    //ESLintに対応しているファイルはESLintでフォーマット
    "source.fixAll.eslint": true
  },
  "typescript.updateImportsOnFileMove.enabled": "always"
}

{
  "recommendations": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
}

バック

こちらもformatterの設定のみ。

{
  "go.toolsManagement.autoUpdate": true,
  "emeraldwalk.runonsave": {
    "commands": [
      {
        "cmd": "goimports -w ${file}",
        "match": "\\.go$"
      }
    ]
  }
}

{
  "recommendations": [
    "golang.go",
    "emeraldwalk.runonsave"
  ]
}

快適なVSCodeライフを。

ちゃなべの備忘録

ほぼ備忘録です。