VSCode 中級者になるための Tips 集

こんにちは！

エージェンシー事業部でアプリケーションエンジニアをしている23新卒の森田です！

4,5年前に Atom から VSCode に乗り換えてすっかり VSCode のことを相棒だと信じ、もう知らぬことはないとそう思っていました。
しかし、今年エンジニアとして業務で VSCode を使用していると、「あれっ、そんなこともできるの？」と日々相棒の新しい機能を発見しています。
完全に理解したと思ったところからさらに新しい面に気づかせてくれる VSCode は最高の相棒ですね！！

そんなところでこのブログでは、VSCode を完全に理解した VSCode 初心者の僕が、VSCode やっぱわからん VSCode 中級者になるために使いこなす必要がありそうだなと思った機能の Tips 集をご紹介します。

筆者の環境は以下のとおりです。

• Mac
  • Apple シリコン
  • Ventura 13.3.1(a)
• VSCode: 1.84.2

はじめに

このブログでは、前述したように業務で VSCode を使用するにあたって、僕が「使いこなすと便利だな」と思った機能と僕が実際に使用している例を紹介いたします。
VSCode の基本的な使用方法や初心者がとりあえず入れておくべきといったような便利な拡張機能などはこのブログでは紹介いたしません。
なので、下記のような方々はこのブログの内容が参考になるかもしれません。

• 初心者向けの VSCode の記事を読み漁って、VSCode を完全に理解した方
• 業務で VSCode をよりうまく使いこなしたいと思っている方

逆に下記のような方々にはこの記事の内容は合わないかもしれません。

• VSCode なにそれ？って方
• VSCode 入れてみたけど、なにから始めたらいいかわからんって方
  • VSCode は初心者の方向けの記事が大変多くあるのでそちらを是非ご参照ください
  • 一通りコーディングしてみたら「VSCode 拡張機能」などで検索してみると、よりイイ感じの VSCode の使い方ができるようになると思います
• VSCode チョットワカル方

---

閑話休題

弊チームでは、自由にエディタを選択することができます。
僕自身を入れた弊チームのエンジニア 11 人のエディタの使用状況は次のとおりです。

エディタ	人数
RubyMine	6
VSCode	3
Vim	2

RubyMine が使用できる + Rails で開発するのもあって RubyMine が優勢です。
ですが、Rails だけではなく フロントやクラウドインフラも触る弊チームの事情もあって、RubyMine を使用している方でも VSCode を併用している方がいらっしゃるようです。

VSCode が多数派になる日も近い...

話は変わるのですが、僕の同期のデザイナーのみやたくんがブログの中で VSCode について触れています！
このみやたくんのブログを見た時は、遠い異国の地で日本人を見つけた時のような気分になりました...（海外行ったことない）

VSCode は部署を超える...

↓ みやたくんのブログ

終 閑話休題

---

settings.json

僕が VSCode 中級者になるために使いこなす必要があると感じる機能 1つ目は settings.json です！！

VSCode の設定を管理するファイルのことで、⌘ + , で開く GUI 設定エディタの右上のくるってボタンを押下すると開くファイルのことです。

本節ではこのボタンで開くsettings.jsonファイルでできることを紹介していくのですが、settings.json でできることは くるってボタンがある GUI 設定エディタでもできます。
なぜ、settings.jsonの説明をするのって話ですが、僕が普段こちらを使っているからです！！

GUI のほうが使いやすくね？って方は適宜 GUI で同等の作業をしていただければおそらく実現できると思います。

GUI の方も使いこなしたら便利だなとは思うのですが、なかなか重い腰が上がらず...ただ、今まじまじと GUI 見てみると左ペインの内容が割と想像できますね。いつか触ってみます。

ただ、settings.json にも利点はもちろんあります。

• チームで共有できる
• ネットに書いてるやつをコピペできる
• (記事書く時にスクショを撮る数が減って楽)

GUI で設定した項目も settings.json の方に変更が反映されるはずなので、それを共有なりコピペすれば大体上記の利点はあってないようなもんです。
僕はスクショを撮らなくて良いので楽です。

重要な前提知識

VSCode の設定には大きく分けて2種類あります。

• User Settings
  • ユーザ固有の設定で、どのフォルダーで VSCode を開いても適用される設定
• Workspace Settings
  • ワークスペース固有の設定で、VSCode で開いているワークスペースのみで適用される設定
  • シングルフォルダーワークスペースの設定
    • 現在開いているフォルダーのみに適用される設定
  • マルチルートワークスペースの設定
    • VSCode のワークスペース機能を使用して開いている全てのフォルダーに適用される設定

これらの種類を踏まえてうまく設定してこそ VSCode 中級者と言えるものでしょう。
頑張って覚えました。

ここで、微妙な違いなのですが、マルチルートワークスペースの設定のみ、設定ファイルがsettings.jsonではなく.code-workspaceファイル内のsettingsキーにsettings.jsonと同等の内容を記述するようになっています。
ほぼsettings.jsonですね。
節タイトル詐欺になりかねないので、言い訳させておいてください mm

↓ 公式のsettings.jsonのドキュメントはこちら

↓ ワークスペースについてのドキュメントはこちら

↓設定のスコープが狭いほど、広いスコープを上書きするようになります。詳しくはこちら

フォーマッタの設定パスをプロジェクトごとに設定する

複数人で開発するプロジェクトは、リンタやフォーマッタの設定を共有するべきですね。

例えば、Prettierではプロジェクト内のどこかに.prettierrc.jsonなりのファイルを配置してコマンドラインからそのファイルを読むようにして実行していると思います。
VSCode には便利な拡張機能がいっぱいあるので、イイ感じに Prettier を実行してくれる拡張機能 Prettier - Code formatter ももちろんあります。
こちらを使用してイイ感じに Prettier を実行してこそ VSCode 中級者でしょう。

ただ、携わるプロジェクトが一つであれば何も考えずに、prettier.configPath: path/to/.prettierrc.jsonをsettings.jsonに記述すればいいのですが、複数のプロジェクトでそれぞれに.prettierrc.jsonが存在する場合は少し考える必要があります。

具体的には各プロジェクトの.prettierrc.jsonを設定する必要があります。
プロジェクトA の Prettier の設定で プロジェクトB のコードを気付かないうちにフォーマットしてしまい、コミットに紛れてしまうと事故ですね。
これは、前節で触れた Workspace Settingsで解決できます。

Workspace Settings は VSCode で開いているフォルダーの直下に.vscodeフォルダを作成し、その中にsettings.jsonを配置することで設定を適用できるようになります。

例えば、prjA を VSCode で開いているなら、prjA を含むディレクトリ構造は以下です。

prjA
├── .vscode
│   └── settings.json
└── .prettierrc.json

.vscode/settings.jsonを下記のように変更します。

{
    "prettier.configPath": ".prettierrc.json"
}

これでprjAを VSCode で開いている間はprjAの.prettierrc.jsonが Prettier - Code formatter で読み込まれるようになりました！！

後はもう一方のプロジェクトも同様にするだけです。prjBとすると以下のように.vscode/settings.jsonを配置します。

prjB
├── .vscode
│   └── settings.json
└── .prettierrc.json

.vscode/settings.json

{
    "prettier.configPath": ".prettierrc.json"
}

これだけで、それぞれのプロジェクトの Prettier をイイ感じに実行できるようになりました。

さらに、それぞれの.vscode/settings.jsonで下記のようにしてやれば保存時に Prettier を実行してくれます。

{
    "prettier.configPath": ".prettierrc.json",
    "editor.formatOnSave": false, // 意図しないファイルでの自動フォーマットを防ぐ
    "[javascript][html][css]": { // 言語ごとの設定もできる。これは javascript,html,css のファイルのみに有効な設定
      "editor.defaultFormatter": "esbenp.prettier-vscode",
      "editor.formatOnSave": true
    }
}

↓ 言語の識別子はこちらをご覧ください。.jsx が javascriptreact なのは言われないとマジでわからないです。

注意すること

リポジトリ管理しているプロジェクトに.vscodeを追加する場合、.vscodeをリポジトリ管理するかどうかはチームの判断が必要になります。
仮に、リポジトリに入れないとなった時に、リポジトリで管理している.gitignoreに個人の持ち物である.vscodeを追記するのはイケてないです。

なのでこの場合はリポジトリに個人用の.gitignore相当の設定ができる.git/info/excludeに.vscodeを加筆します！！
書き方は.gitignoreと一緒です。

.git/info/exclude

+ .vscode

↓ .git/info/excludeの公式ドキュメントはこちら

チームで共有している.vscode/settings.jsonを自分用にカスタマイズしたい

なかなかないと思いますが、チームで共有している.vscode/settings.jsonを自分用にカスタマイズしたい時の解決方針を共有いたします。
そもそもですが、docker-compose.override.ymlのようにオーバーライドできればこれに書けば解決なのですが、執筆当時この機能はなさそうです。
過去に issue に上がっているようですが、解決されずに Close されていそうです...
僕が VSCode チョットワカル レベルになったら PR を出したいですね。

自分用にカスタマイズしたい時ってどんな時？

根本的に.vscode/settings.jsonの運用を変えたほうがいい時も存在するかもなので、そこから考えていきましょう。

1. .vscode/settings.json に editor.fontSize の設定が入っていて、文字が小さい/大きい
   • これは設定を入れた人に言って、User Settings にその設定を移していただきましょう。チームで共有すべき設定ではないです。
   • ですが、言いにくい時、ありますよね。自分用にカスタマイズする にお進みください。
2. 自分の好みなので他人に共有するほどでもない
   • あなたがいいと感じるなら、他の人もいいと感じてくれると思います。この設定どすか？って話題に上げてみましょう
   • ですが、言いにくい時、ありますよね。自分用にカスタマイズする にお進みください。
3. なんか特定の拡張機能がうまく動かないので、代替の拡張機能を使用したい
   • 将来的に他の人も同じ問題に直面するかもしれないし、もしくは、過去に他の人が直面しているかもしれません。質問してみて解決しましょう
   • ですが、言いにくい時、ありますよね。自分用にカスタマイズする にお進みください。
4. 他
   • 自分用にカスタマイズする にお進みください。

自分用にカスタマイズする

自分用にカスタマイズする方法ですが、先述した通り、最高の解決方法であるところの.vscode/settings.override.jsonのようなオーバーライドが使用できないです。
ですので、ここで紹介するのはあくまでワークアラウンドであることをご承知ください。

解決方法としては下記を考えています。

1. settings.json.defaultをリポジトリ管理する
2. ワークスペース機能を用いる
3. .vscode/settings.json を触ってコミットしないように気を付ける

順番に見ていきましょう。

1. settings.json.defaultをリポジトリ管理する

そもそも、.vscode/settings.json を直接リポジトリ管理しない運用方法です。

チームで共有すべき設定をsettings.json.defaultなどのファイルで共有しておき、各々の環境で.gitignoreで除外されている.vscode/settings.jsonにコピペする方法ですね。
この方法なら.vscode/settings.jsonは触り放題なのでやりたい放題カスタマイズできます。

この方法のデメリットとしては、settings.json.defaultに差分が出た際に作業が発生するのでめんどくさいところですね。

ワークアラウンドとしては、この方法が一番スマートだと僕は考えています。

2. ワークスペース機能を用いる

前述した マルチルートワークスペースの設定 の設定ファイル .code-workspace の方に自分用の設定を記述する方法です。

このコメントで言及されている方法ですね。
ただ、この方法には大きめのデメリットがあって、.code-workspaceの内容を.vscode/settings.jsonが上書きしてしまうことです。

.vscode/settings.json の editor.fontSize を変えたい時、.code-workspaceの方に記述しても変更できないということですね...
残念。

ただ、自分だけが使って見ている拡張機能の設定を書くとかはできそうです！！

3. .vscode/settings.json を触ってコミットしないように気を付ける

リポジトリ管理している .vscode/settings.json を触る方法ですね。 事故率が高いのでやめましょう。

以上です。
スマートに解決したいところですが、なかなか難しそうですね...
チームレベルで運用の最適化が理想ですが、そうもいかないこともあると思うのでうまく乗り越えていけたらいいですね。
僕が携わっているプロジェクトではまだ.vscode/settings.jsonをリポジトリ管理していないのですが、リポジトリ管理するようになった暁には 1 の方法でイイ感じにしようと考えています。

.code-snippets

僕が VSCode 中級者になるために使いこなす必要があると感じる機能 2つ目は .code-snippetsです！！

正確には*.code-snippetsですし、GUI での設定がないので Code Snippets(コードスニペット) とだいたい一意です。
どうでもイイですね。

コードスニペットとは、ちょっとしたコードのテンプレートを呼び出せる機能のことです！！

例えば次の画像の for とかのことですね。

これを使用しているのが次の gif です。

fo しか打ってないのに、それっぽいfor文を挿入してくれています！！すごい！！

VSCode には次の3種類のコードスニペットがあります。

• 組み込みのもの
• 拡張機能で追加されるもの
• 自分で作るもの

本ブログでは、*.code-snippetsに記述して自分で作成するコードスニペットの使用例を紹介いたします！

なお、*.code-snippetsにもsettings.jsonで言うところの User Settings と Project Settings のようなものがありますが、ここでは Project スコープの*.code-snippetsを紹介します。

---

なんで自作すんの？って話、ありますよね。

自作する利点をちょっと紹介します。

• 組み込み、拡張機能では足りない時がある
• ちょっとしたものなら探すより早い
• 自分好みのコードスニペットを作成できる
• (ブログに書ける)

こんな感じです。重要そう。

---

↓ 公式の Snippets のドキュメントはこちら

ちょっとしたマジックコメントを入れる

どんなファイルにも記述が必要なコードのコードスニペット化は結構コスパが高いです。
例えば、shebang とかマジックコメントとかですね。

僕は Rails の開発をする際に使用する # frozen_string_literal: true をコードスニペットとして登録しています。

.
├── .vscode
│   └── ruby.code-snippets
└── hoge.rb

2 directories, 2 files

.vscode/ruby.code-snippets

{
  "frozen": {
    "prefix": "frozen", // これを打つと候補に上がるようになる
    "body": "# frozen_string_literal: true", // コードスニペットを適用すると反映される内容
    "scope": "ruby" // 言語ごとにスコープを絞れる。
}

こんな感じですね。簡単です。
残念ながら下記のような記述はできません、残念。

// 注：この記述は不可
{
  "[ruby]": {
    "frozen": {
      "prefix": "frozen",
       "body": "# frozen_string_literal: true"
     }
  }
}

これで frozen とか fro とか打って tab するだけで # frozen_string_literal: true を挿入してくれます！！一瞬ですね。

プロジェクトのコードスニペットは好きなファイル名を使用できるので、運用方法に合わせて作成してください。
僕の場合は、この例のように言語ごとにファイルを作成して管理しています。
いつの日か上位で言語でのスコープが絞れると信じて、今はコードスニペットごとにスコープを設定しています。

JavaScript の default export

React などを書いているとき export default function という構文が長すぎると思うことがありますよね。
僕は3回くらい思ったのでコードスニペット化しました。
ここでは、export default function の例を紹介しますが、他の言語やフレームワークの関数宣言にも応用できると思います。

ちょっとしたマジックコメントを入れると同様サクッと作っていきましょう。

.vscode/javascript.code-snippets

{
  "export default function": {
    "prefix": "edf",
    "scope": "javascript",
    "body": "export default function"
  }
}

サクッ

できましたが、僕のもうひとりの相棒こと GitHub Copilot 君も 続きあるやろ？ と提案してくれている通り、関数には他にも書きたいことがあるはずですね。
具体的には下記を関数周りでは触りたいです。

• 関数名
• 引数
• 関数の中身

これはコードスニペットの Tabstops の記述で解決できます。
具体的には下記のように書き換えます。

.vscode/javascript.code-snippets

{
  "export default function": {
    "prefix": "edf",
    "scope": "javascript",
-    "body": "export default function"
+    "body": [
+      "export default function ${1}(${2}) {",
+      "\t${0}",
+      "}"
+    ]
  }
}

このように変更すると次のようになります。

ポイントとしては以下だと思います。

• 複数行のコードスニペットは配列で渡す
• タブを挿入する時は \t で入れる
• ${n} の記述をするとtabで移動できる
  • gif だとわかりにくいのですが、関数名 -> 引数 -> 中身 の順に tab キーで移動しています
  • ${1} -> ${2} -> ... -> ${0}の順番で移動する
  • ${0} まで行くと、tabキーの挙動が普段と同じ挙動に戻る

ここで、僕はコンポーネントを返す関数もコードスニペット化したいと思いました！！！！(ブログに書けるので)

なお、下記の規則のプロジェクトであるとします。

• コンポーネントを返す関数をexport defaultする時はファイル名と同じ関数名で定義する
• ファイル名はスネークケース
• 関数名はパスカルケース

つまりこんな感じの規則のプロジェクトです。

foo_bar.jsx

export default function FooBar(args) {
  return (
    <>
      baz
    </>
  )
}

ファイル名と関数名の命名規則に関連性があるなら利用したいですよね。
僕はしたい。

コードスニペットはこれも解決できます！！

具体的にはこうします。

.vscode/javascriptreact.code-snippets

{
  "export default component function": {
    "prefix": "edf",
    "scope": "javascriptreact",
    "body": [
      "export default function ${TM_FILENAME_BASE/(.*)/${1:/pascalcase}/}(${1}) {",
      "\treturn (",
      "\t\t<>",
      "\t\t\t${0}",
      "\t\t</>",
      "\t)",
      "}"
    ]
  }
}

スネークケースのファイル名foo_bar.jsxがパスカルケースの関数名FooBarに反映されていることが確認できます。
最高ですね。

ここのポイントは以下です。

• ${TM_FILENAME_BASE/(.*)/${1:/pascalcase}/}
  • 一般化すると ${VAR/regex/${1:/option}}
    • /で繋げてそれぞれの記述をしています
    • ${1:/option}}が置換の書き方もあるぽい
  • TM_FILENAME_BASE
    • VAR の部分
    • コードスニペットでは変数を扱うことができ、TM_FILENAME_BASEは拡張子を除いたファイル名の変数です
  • (.*)
    • regex の部分
    • 正規表現です。全ての部分を受けてます
  • pascalcase
    • option の部分
    • パスカルケースを指定してます。便利

ここまで来るとチョットややこしいですが、一度作れば生産性爆上がり間違いなしなので中級者らしく使いこなしたいです！！

↓.code-snippetsで使用できる変数はこちら

↓optionの公式ドキュメントは見つけられなかったのですが、こちらの記事がまとめてくださってます

keybindings.json

僕が VSCode 中級者になるために使いこなす必要があると感じる機能 3つ目は keybindings.json です！！

VSCode 上で使用できるキーボードショートカットを定義できるファイルのことで、⌘ + k ⌘ + sで開く GUI キーボードショートカット設定エディタの右上のくるってボタンを押下すると開くファイルのことです。

キーボードショートカットを制するものは開発生産性を制するかもしれないので、是非とも使いこなしたい機能ですね！！

keybindings.jsonはsettings.jsonや.code-snippetsで言うところの User スコープ しか存在しません。
ちょっとした手間を加えれば Project スコープのような挙動をするように変更できますので、後ほど紹介いたします。

また、keybindings.json は GUI にできないことも結構できます。

例えば、一つのショートカットキーに複数の処理をさせるとかですね！！
これについては、僕自身まだまだ発見中なのであまり触れることができません！！
僕の中級者への道は始まったばかりです！！！！

↓ 公式の keybindings.json のドキュメントはこちら

エディタ領域を広くする

お気づきでしょうか。
先ほどからの僕の VSCode の画面のキャプチャ。
エディタ領域が広いです。

デフォルトの状態だと次のようにアクティビティバー(アイコンが並んでるところ)とサイドバー(画像だとエクスプローラーが開いていてファイルが並んでるところ)が開いています。

一方で僕の VSCode はどちらも開いていなくてエディタ領域が一面に広がっています。

コーディングしやすそうですよね？しやすいです！！

アクティビティバーとサイドバーは常に見えていて欲しい情報ではなく、欲しい時にだけ見えていたらいいなって僕は思っています。

なので、普段は閉じていて、欲しい時にだけショートカットキーで開いています。

サイドバーはデフォルトで開閉できるショートカットキーが ⌘ + b に設定されています。
一方でアクティビティバーの方はデフォルトで開閉できるショートカットキーは設定されていません。

そこで、keybindings.jsonの出番です！！

keybindings.json を開いて、次を加筆します。

{
    "key": "cmd+shift+b",
    "command": "workbench.action.toggleActivityBarVisibility"
},

これだけで、アクティビティバーが ⌘ + ⇧ + b で開閉できるようになります！！
簡単ですね！！

（workbench.action.toggleActivityBarVisibilityはどこからわかるねん、って話ですが、GUIで検索しました。これが一番早いと思います。）

なぜか効かないショートカットキーを復活させる

なぜか効かないショートカットキーみなさんありませんか？？
僕はありました...
同じ悩みを抱えてる皆さんのために僕のワークアラウンドを共有します。

GUI から効かないショートカットキーを検索して、右クリック -> コピー で keybindings.json に貼り付けです。
簡単ですね。

僕の場合はターミナルの移動の ⌘ + ⇧ + [ or ] が効かなかったんですが、keybindings.json から削除したら動きました...なんでや...

ショートカットキーにどの機能が設定されているか確認する

ショートカットキーを設定しようにも、既存のショートカットキーとバッティングすると困りますよね。
そんな時は便利な機能が GUI にあります。

GUI を ⌘ + k ⌘ + s などで開いていただくと、右上にキーボードのボタンが確認できると思います。

このボタンをクリックすると、キーを記録していますと表示され、この間に入力したキーが設定されているものを検索してくれます！！

プロジェクト固有のキーバインドを設定する

先ほどもちろっと触れましたが、User スコープにしか定義できないショートカットキーを Project スコープっぽい挙動をするように変更できます！！

例えば、フォーマッタの設定パスをプロジェクトごとに設定するで登場したそれぞれの Prettier の設定を抱えているプロジェクトAとプロジェクトBを考えます。
↓このような構成です。

prjA
├── .vscode
│   └── settings.json
└── .prettierrc.json

prjA/.vscode/settings.json

{
    "prettier.configPath": ".prettierrc.json"
}

prjB
├── .vscode
│   └── settings.json
└── .prettierrc.json

prjB/.vscode/settings.json

{
    "prettier.configPath": ".prettierrc.json"
}

このプロジェクトAのみで JavaScript の default export で作成したコードスニペットを使用したいとします。
↓これですね

プロジェクトAで想定される foo_bar.jsx

export default function FooBar(args) {
  return (
    <>
      baz
    </>
  )
}

.vscode/javascriptreact.code-snippets

{
  "export default component function": {
    "prefix": "edf",
    "scope": "javascriptreact",
    "body": [
      "export default function ${TM_FILENAME_BASE/(.*)/${1:/pascalcase}/}(${1}) {",
      "\treturn (",
      "\t\t<>",
      "\t\t\t${0}",
      "\t\t</>",
      "\t)",
      "}"
    ]
  }
}

---

プロジェクトBで使用したくない理由としてはプロジェクトBが↓アロー関数式派なんでしょうか。

プロジェクトBで想定される foo_bar.jsx

const FooBar = (args) => {
  return (
    <>
      baz
    </>
  )
}

export default FooBar;

くせで関数宣言の方をコードスニペットで使うため、制限をしたいってことですね。

---

さらに、今回はedfすらタイプするのがめんどくさくなったので、⌘ + ⇧ + c で上記のコードスニペットを呼び出したいです！！ブログを書くために！！

keybindings.json

{
  {
    "key": "cmd+shift+c",
    "command": "editor.action.insertSnippet",
    "when": "editorTextFocus",
    "args": {
        "name": "export default component function"
    }
  }
}

keybindings.jsonの設定はこんな感じです。

• commandキーにeditor.action.insertSnippetを指定
• args の name にコードスニペットの定義のキーを渡す
• when は キーボードショートカットが有効になる条件を指定する
  • 今回はエディタのテキスト部分にフォーカスがある時です
  • ターミナルとかにフォーカスがあると効かない感じですね。

今回はexport default component functionの名前がついたコードスニペットが定義されていないプロジェクトではこのショートカットキーは効きません。
ですが、なんか気持ち悪いですよね。グローバルが汚れている感じがします。
効かないだけで動いてそう。

なので、今回はプロジェクトAだけでこのキーボードショートカットを動いてる風にします！！

具体的には次のように変更します。

prjA/.vscode/settings.json

{
    "prettier.configPath": ".prettierrc.json",
+   "workspaceKeybindings.prjA.enabled": true
}

keybindings.json

{
  {
    "key": "cmd+shift+c",
    "command": "editor.action.insertSnippet",
-   "when": "editorTextFocus",
+   "when": "config.workspaceKeybindings.prjA.enabled && editorTextFocus",
    "args": {
        "name": "export default component function"
    }
  }
}

settings.json の Project Settings に keybindings.json の when 条件で参照する設定を追加する方法です！！

こうすれば他のプロジェクトでは when で絶対弾かれるので動かないですね。安心。心が綺麗になった気分です。

補足としては以下です。

• settings.json では好きな設定を追加できる
• keybindings.json からは config.*で参照できる

↓参考にしたのはこちら

stackoverflow.com

tasks.json

僕が VSCode 中級者になるために使いこなす必要があると感じる機能 最後は tasks.json です！！

だいたいなんでもできそうなまさに最強で無敵の機能です。
僕自身、どこまでできるのかこれから知っていく機能ではあるのですが、ビルドタスクとか、フォーマット、リント、テストをまとめて実行できるようになります。
すごいな？？？？

ここでは、まだtasks.jsonを知り始めた僕が使用しているものを紹介します！！

↓ 公式の tasks.json のドキュメントはこちら

現在開いているファイルのテストを実行する

僕は普段、Rails を開発する際は Docker コンテナを用いています。
その中で、「このファイルのテスト開いて、相対パスコピーして、ターミナル開いて、docker-compose exec container_name bundle exec rspec 相対パス打つのめんどくさい」って思ってました。
(実際には zsh がいい感じに補完してくれますし、.zshrc に docker-compose exec container_name bundle exec rspec コマンドを crspec という名前でエイリアス設定を行っているのでそんなにめんどくさくはありませんが、ブログなので)

今回の問題を解決するために達成しないといけない点をまとめると次の2点になります。

• テストファイルのパスを取得
• コンテナ内の RSpec を実行する

他にも考えるべき点はあるんですが、そこはプラスアルファですね。

なお、この設定は Rails のディレクトリ構成とファイルの命名規則によります。
必要ならご自身の環境に合わせて${relativePath}から RSpec の相対パス取得を書き換えてください。
もしくは、拡張機能に現在開いているファイルに対応するテストファイルを開くものがあるよう(観測できてない)なので、そちらをご使用ください。

他の言語のテストでも、ディレクトリ構成とファイルの命名規則がしっかりしていれば応用可能です！！
うまく使いこなしてテスト実行を快適にしてみてください！！

.vscode/tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Run RSpec for Current File",
      "type": "shell",
      "command": "./mysh/run_rspec_from_file.sh ${relativeFile}",
    }
  ]
}

mysh/run_rspec_from_file.sh

#!/bin/bash

test_file=$(echo $1 | sed 's/app/spec/' | sed 's/.rb/_spec.rb/')

docker-compose exec container_name bundle exec rspec $test_file

今回はこんな感じで設定しています。
ポイントは下記です。

• typeにshellを設定
  • コマンドを実行するタスクになる
• ${relativePath}でタスクを実行した時のファイルのパスを取得
• commandからシェルスクリプトを呼び出す
  • パス文字列のappをspecに、.rbを_spec.rbに置換
    • ex) app/path/to/hoge.rb -> spec/path/to/hoge_spec.rb
  • コンテナ内でrspecコマンドを実行

ここまで設定したところで、⌘ + ⇧ + p -> Tasks: Run Task -> Run RSpec for Current File で開いているファイルに対応するテストを実行してくれます！！
テスト実行までの手順がめんどくさいですね！！！！

なので、Run RSpec for Current Fileにショートカットキーを設定します。

keybindings.json

{
  "key": "cmd+r",
  "command": "workbench.action.tasks.runTask",
  "args": "Run RSpec for Current File",
  "when": "editorTextFocus && editorLangId == ruby"
},

こんな感じで、

• command に workbench.action.tasks.runTask
• args に tasks.json に設定した label

を設定することで、ショートカットキーでタスクを実行することができます！！
やったぜ！！

ちなみに、コンテナの中の RSpec を実行するケースですが、特定のプロジェクトのために設定しているので実際には↓のように設定しています。

keybindings.json

{
  "key": "cmd+r",
  "command": "workbench.action.tasks.runTask",
  "args": "Run RSpec for Current File",
- "when": "editorTextFocus && editorLangId == ruby",
+ "when": "config.workspaceKeybindings.prj.enabled && editorTextFocus && editorLangId == ruby"
},

↓tasks.jsonで使用できる変数の一覧はこちら

プラスアルファ

ここで蛇足なんですが、この設定にはまだ満足いってないので今後の改良点を挙げておきます。
誰かいい感じに設定できたら教えてください。

• specファイルの時はそのファイルをテストするようにする
  • テストファイルに対するテストファイルを実行する謎の挙動を発揮してしまう
• ファイルを保存した時に自動でテストするようにする
  • 拡張機能を使う必要がある
  • https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.triggertaskonsave

おわりに

このブログでは、VSCode 中級者になるために僕が使いこなす必要があると感じている設定になぞってその Tips を紹介いたしました。
VSCode は拡張機能を触るだけでもいい感じになりますが、もう一歩踏み込んだ設定をすることでより使いやすくなっていきます。
みなさんもぜひ自分なりの設定を見つけてみてください。

本ブログを最後までお読みいただきありがとうございました！！