GoogleのProfessional Cloud Developer認定試験の勉強で残したメモ書きです

Professional Cloud Developer認定試験の学習メモ書き

先日、Googleが実施しているProfessional Cloud Developerの認定資格に合格しました。🎉 
自分が認定試験に合格するまでに行った学習の振り返りです。
<h2 id="Professional Cloud Developer(PCD)とは？">Professional Cloud Developer(PCD)とは？</h2>
<a href="https://cloud.google.com/certification/cloud-developer?hl=ja" target="_blank">Professional Cloud Developer</a>はGoogleが推奨するツール（主にGCP）とベストプラクティスを使用して、スケーラブルで可用性の高いアプリケーションを構築する知識に基づいた認定資格です。
出題内容としては次のスキルについて評価がされます。
<ul>
<li>スケーラビリティ、可用性、信頼性に優れたクラウドネイティブ アプリケーションの設計</li>
<li>アプリケーションのビルドとテスト</li>
<li>アプリケーションのデプロイ</li>
<li>Google Cloud サービスの統合</li>
<li>デプロイされたアプリケーションの統合</li>
</ul>
<h2 id="受験の経緯">受験の経緯</h2>
会社でG.I.GプログラムというGoogle Cloudの技術スキルを習得するためのエンジニア向けのプログラムに参加させて頂けることになりました。このプログラムの修了過程の一環としてGoogle Cloud認定資格の取得があります。
前からCGPをちゃんと勉強してみたいと思っていたので、折角の機会に認定試験を資格を受験してみようとなりました。
<h2 id="筆者の開発経験">筆者の開発経験</h2>
<h3 id="実装・設計の経験">実装・設計の経験</h3>
<ul>
<li>サーバーサイドの開発経験: 2.5年</li>
<li>フロントエンドの開発経験: 3年</li>
</ul>
<h3 id="インフラ経験">インフラ経験</h3>
<ul>
<li>Next.jsを本番運用するためにTerraform + AWS Fargate でインフラ構築及び運用の経験あり
<ul>
<li>既に土台があったので、それを真似して知っている人に相談しながら構築</li>
</ul>
</li>
<li>Node.js + Lambda でAPIの構築経験あり</li>
<li>AWSの基本的なサービスは知っている状態</li>
<li>GCPはコンソールの見方も分からず苦手意識がありGCP怖い状態</li>
</ul>
<h2 id="学習方法">学習方法</h2>
<h3 id="学習時間と期間">学習時間と期間</h3>
学習時間: 約60時間 
学習期間: 2ヶ月
合計の学習時間は約60時間でしたが、Courseraのコースを修了するにあたりハンズオンを完了させる必要があり1/4はその時間に費やしていた気がするので、単純な座学の時間だけだと約45時間でした。
<h3 id="Coursera">Coursera</h3>
G.I.Gプログラム参加者に提供されているCouseraのPCD受験者向けの学習コースを5つ受講・修了しました。実施内容は動画視聴によるGCPに関する学習とQwiklabsでのハンズオンです。
動画を視聴しているだけど頭に入ってこなかったので、学習動画を視聴しながら重要だなと思った点をメモ帳にメモ書きしながら、分からない単語やサービス名をドキュメントや他の人のブログ記事などを読んで理解するようにしていました。このやり方は動画視聴しているだけの時と比較して学習の質が上がったと実感できました。
<a href="/post/gcp-memo">Professional Cloud Developer認定試験の学習メモ書き</a>でメモ書きの内容を書いているので、興味ある方は確認してみてください。
具体的には次のコースを受講しました。一般向けにも公開もされているので、G.I.Gプログラム参加者以外でも受講は可能だと思います。
<ul>
<li><a href="https://www.coursera.org/learn/gcp-fundamentals-jp" target="_blank">Google Cloud Fundamentals: Core Infrastructure 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/app-deployment-debugging-performance-jp" target="_blank">Application Deployment, Debug, Performance 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/securing-integrating-components-app-jp" target="_blank">Securing and Integrating Components of your Application 日本語版 
</a></li>
<li><a href="https://www.coursera.org/learn/getting-started-app-development-jp" target="_blank">Getting Started with Application Development 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/google-kubernetes-engine-jp" target="_blank">Getting Started with Google Kubernetes Engine 日本語版</a></li>
</ul>
<h3 id="模擬試験">模擬試験</h3>
Courseraコースを一通り受講し終えた後に<a href="https://docs.google.com/forms/d/e/1FAIpQLSc_67KaPnNwQrLZ7kuhw-aubz7gMAwY6DQwRJYcW0qlG-iajA/viewform?hl=ja" target="_blank">公式の模擬試験</a>を解いてから、知らないサービス名などの単語を全て調べて理解することをしていました。その後、何も見ずに解答の説明ができるように繰り返し解いていました。
<h2 id="難易度と雑感">難易度と雑感</h2>
選択式の試験だったのでGCPのサービスだけ把握すれば、システム構築に関する問題は経験則の勘で答えられるだろうと思っていましたが、実際にそんな感じで解答できました。
設計を含めたサーバーサイドの開発経験がある程度あれば、比較的難しくないのかな？という印象でした。特に業務でGCPを利用している方であれば、模擬試験を受けて試験の傾向と雰囲気だけ把握して少し勉強するだけでも合格できると思います。

GoogleのProfessional Cloud Developer認定試験に合格するためにやったことの振り返りです

GoogleのProfessional Cloud Developer認定試験に合格するまでの学習の振り返り

Electronアプリのリポジトリ構成をMonorepo構成に変更したので、その時の内容をまとめました。

ElectronアプリをMonorepo構成で構築

HTMLを仕様に基づいて正しく書くには思ったよりも必要な専門知識が必要です。 
例えば以下のコードは<code>p</code>要素で許可されている内容は記述コンテンツのみなので、HTMLの仕様としては誤ったコードになります。
<pre class="language-html"><code class="language-html">&lt;p>
 &lt;h1>見出し&lt;/h1>
&lt;/p>
</code></pre>
<h2 id="HTMLの仕様に基づいてコーディングする目的">HTMLの仕様に基づいてコーディングする目的</h2>
先ほどのコードはHTMLとしては構文エラーとなりますが、ブラウザ上では問題なく表示されます。見た目上問題ないのであれば、些細な問題なので別に良いのでは？と思うかもしれません。
ページを閲覧する対象は人だけでなくスクリーンリーダーや検索BOTなどの機械も含まれます。これらの機械が正確にページを解釈するには、HTMLの仕様に基づいて正しく記述されている事が重要になってきます。
<h2 id="markuplintの導入">markuplintの導入</h2>
最初にも書いたように仕様に基づいてHTMLを記述するのは一定の専門知識が必要です。知識を持つ人がプルリクのタイミングでコードをチェックする事も可能ですが、それをするには全てコードをレビューする必要があり負担が膨大になります。
<a href="https://markuplint.dev/" target="_blank">markuplint</a>を利用することで、HTMLの構文チェックを自動化でき全員が実装の段階で構文エラーに気づく事ができるようになります。また、構文エラーを通してHTMLの仕様を学ぶことも出来るので一石二鳥です。
<h3 id="インストール">インストール</h3>
まずは必要なパッケージをインストールします。
<code>markuplint</code>パッケージはHTML構文チェクのコア機能を提供するCLIツールです。
<code>@markuplint/jsx-parser</code>パッケージはjsxで記述されたコードをHTML文字列にパースして構文チェック可能にするためのパッケージです。
<code>@markuplint/react-spec</code>パッケージはReactで定義されている<code>key</code>属性などを仕様として認識されるためのパッケージです。Reactのコードを構文チェックすると<code>error: 属性「key」は許可されていません (invalid-attr)</code>とHTML仕様に定義されていない<code>key</code>属性が不正な属性として検知されてしまうため、それを防ぐためにこのパッケージをインストールします。
vueやsvelteなどの他のライブラリに対応したparserやspecは<a href="https://github.com/markuplint/markuplint/tree/dev/packages/@markuplint" target="_blank">公式リポジトリ</a>で探すことができます。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint @markuplint/jsx-parser @markuplint/react-spec
</code></pre>
<h3 id="設定ファイルを作成">設定ファイルを作成</h3>
プロジェクトのルートに<code>.markuplintrc</code>を以下の内容で作成します。
<pre class="language-json"><code class="language-json">// .markuplintrc
{
 // テストファイルやストーリーファイルを除外
 "excludeFiles": [
 "./**/*.{test,spec,stories}.tsx"
 ],
 // ツールの推奨設定を利用
 "extends": [
 "markuplint:recommended"
 ],
 // jsxをHTMLテキストにパース
 "parser": {
 ".tsx$": "@markuplint/jsx-parser"
 },
 "specs": {
 ".tsx$": "@markuplint/react-spec"
 }

}
</code></pre>
<h3 id="構文チェックを実行する">構文チェックを実行する</h3>
実際に以下のコンポーネントファイルを対象として構文チェックを実行してみます。
<pre class="language-tsx"><code class="language-tsx">// src/
const Hello = () => {
 return (
 &lt;p>
 &lt;h1>こんにちは&lt;/h1>
 &lt;/p>
 )
}
</code></pre>
構文チェックの対象をblobパターンで指定をして実行をします。デフォルトでは対象ファイルの全て結果が表示されるので、<code>-p</code>オプションを付与することでエラーだけを出力するようにできます。
無事にHTMLの構文エラーが検出することができました。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint -p src/**/*.tsx
&lt;markuplint> error: HTMLの仕様において、要素「p」の内容は妥当ではありません (permitted-contents) 
 4: ••••••••&lt;p>
 5: ••••••••••••&lt;h1>テスト&lt;/h1>
</code></pre>
VSCodeを利用している場合には<a href="https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint" target="_blank">markuplintプラグイン</a>もあるので、合わせてインストールしておくと便利です。

Reactのプロダクトにmarkuplintを導入する

freeeさんが公開しているアクセシビリティー・チェックリストを活用して個人のブログのアクセシビリティーをチェックして改善をしてみました。

個人ブログのアクセシビリティー・チェックと改善を実践してみた

この記事は<a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア アドベントカレンダー2022</a> 14日目の記事です。
業務でReactで実装されたフォームのパフォーマンス改善をしたので、その時の問題を一般化してパフォーマンス改善を体験できる練習問題を作ってみました。
<h2 id="練習問題">練習問題</h2>
Reactで<code>&lt;input&gt;</code>要素がリストで表示されており、<code>&lt;input&gt;</code>要素にテキストを入力してみると非常にレスポンスが遅い状態になっています。このレスポンス速度を改善するのが今回の問題です。
<iframe src="https://stackblitz.com/edit/react-ts-evcw6y?embed=1&file=src/App.tsx" style="width: 100%; height: 400px"></iframe>
ソースコードを眺めてみるとApp.tsxでTodoの一覧を管理しており<code>TotoList</code>コンポーネントを描画しています。 
<code>onChange</code>propsには<code>setTodos</code>を渡しておりTodoの一覧を更新します。
<pre class="language-tsx"><code class="language-tsx">// App.tsx
const initialTodos: TodoModel[] = [...Array(100)].map((_, i) => ({
 id: i,
 text: 'aaa',
}));

const App = () => {
 const [todos, setTodos] = useState(initialTodos);

 return (
 &lt;div>
 &lt;button
 onClick={() => {
 alert(todos[0].text);
 }}
 >
 保存
 &lt;/button>
 &lt;TodoList todos={todos} onChange={setTodos} />
 &lt;/div>
 );
};
</code></pre>
次に<code>TodoList</code>コンポーネントの実装を見てみます。
<code>TodoList</code>では<code>&lt;input&gt;</code>要素として<code>Todo</code>コンポーネントを描画しており、変更があったときに新しい<code>Todo</code>のオブジェクトを受け取り新しいTodoリストを引数としてpropsで渡された<code>onChange</code>コールバック関数を実行して、親要素に新しいTodoリストを渡しています。
<pre class="language-tsx"><code class="language-tsx">export const TodoList: FC&lt;TodoListProps> = ({ todos, onChange }) => {
 const handleChange = useCallback(
 (updatedTodo: TodoModel) => {
 const index = todos.findIndex((todo) => todo.id === updatedTodo.id);
 onChange?.([
 ...todos.slice(0, index),
 updatedTodo,
 ...todos.slice(index + 1),
 ]);
 },
 [onChange, todos]
 );

 return (
 &lt;ul>
 {todos.map((todo) => {
 return (
 &lt;li key={todo.id}>
 &lt;Todo todo={todo} onChange={handleChange} />
 &lt;/li>
 );
 })}
 &lt;/ul>
 );
};
</code></pre>
最後に<code>Todo</code>コンポーネントの実装を見てみます。
<code>Todo</code>コンポーネントではpropsで受け取った<code>todo</code>のテキストの内容を<code>&lt;input&gt;</code>要素のvalueとして表示しています。テキストが変更された時に新しいテキストでTodoオブジェクトを作成して<code>onChange</code>関数を実行して親要素に新しいTodoオブジェクトを渡しています。
<code>[...Array()]</code>はコンポーネントの描画速度を疑似的に遅くするために仕込んでいます。は問題を作成するための疑似コードなので、ここを削除しないでください。
<pre class="language-tsx"><code class="language-tsx">export const Todo: FC&lt;TodoProps> = memo(({ todo, onChange }) => {
 [...Array(100000)].forEach(() => 1 + 1);

 return (
 &lt;input
 type="text"
 defaultValue={todo.text}
 onChange={(evt) => {
 onChange({
 ...todo,
 text: evt.target.value,
 });
 }}
 />
 );
});
</code></pre>
このコンポーネント単体の描画速度は約10msほどになっており、実際の実装でも再現し得る問題になっています。
<img src="/images/posts/react-performance-question/profile.png" alt="プロファイルの結果" width="1136" height="462" />
<h2 id="解説">解説</h2>
問題の解答は別の記事で書こうと思います。 
興味があれば解いてみてください。

業務でReactのパフォーマンス改善をする機会があったので問題を一般化して練習問題を作ってみました

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

<h2 id="Google検索で見つかるサンプル実装の課題">Google検索で見つかるサンプル実装の課題</h2>
Checkboxのデザインをカスタマイズするには、従来のCheckboxでは難しく自前でCheckboxを実装する必要があります。Googleで「チェックボックス デザイン 変更」と検索して上位に出てくる記事を見ると次のサンプルのように<code>input[type=&quot;checkbox&quot;]</code>を<code>display:none</code>で非表示にしている実装が多くあります。
この実装では<code>&lt;input&gt;</code>要素にフォーカルを当てることができないため、Tabキーで選択してスペースでトグルするようなキーボード操作ができない状態になっています。 
また、スクリーンリーダーがチェックボックスを認識できないので、スクリーンリーダーユーザーはチェックボックスの存在に気づくことすらできません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/BadCheckbox/style.css&initialpath=?bad" style="width: 100%; height: 400px;"></iframe>
<h2 id="アクセシビリティを考慮してチェックボックスを実装">アクセシビリティを考慮してチェックボックスを実装</h2>
<code>display:none</code>だとフォーカスができなくなってしまうので、代わりに<code>opacity:0;</code>で<code>&lt;input&gt;</code>を非表示にします。 
<code>&lt;input&gt;</code>は非表示のままのため、フォーカスが当たっている時のデザインを追加します。
この考慮を入れて上げるだけで、キーボード操作可能になり操作性が上がりスクリーンリーダーユーザーもチェックボックスの操作が可能になります。
<pre class="language-css"><code class="language-css">/* src/GoodCheckbox/style.css */

/* 元のチェックボックス（非表示） */
input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

/* フォーカスが当たっている時のデザインを追加 */
input[type='checkbox']:focus-visible + label::before {
 border-color: blue;
}
</code></pre>
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/GoodCheckbox/style.css" style="width: 100%; height: 400px;"></iframe>
<h2 id="デザイン実装をリファクタする（おまけ）">デザイン実装をリファクタする（おまけ）</h2>
ここから先は好みの問題かもですが、CSSを利用したサンプル実装は疑似要素を使った実装になっており直感できないため、少し保守がしづらく感じます。疑似要素を使わずに直感的にデザイン指定できるようにリファクタをしてみます。
疑似要素を使わずにカスタムなチェックボックスを<code>&lt;span&gt;</code>タグで実装してCSSでデザインを指定することで、宣言的になり直感的に分かりやすくなりました。
チェックアイコンを<code>&lt;svg&gt;</code>タグで直接表示するように変更しています。この時の注意点としてチェックアイコンの画像は視覚的な情報なのでスクリーンリーダーユーザーにとっては唯のノイズになってしまいます。実際に<code>aria-hidden</code>を消してスクリーンリーダーに読み上げさせると、チェック済みの場合に「イメージ」という無駄な読み上げが発生します。そのため、忘れないように<code>&lt;svg aria-hidden=&quot;true&quot;&gt;</code>と設定してあげる必要があります。<code>@mui/icons-material</code>ではデフォルトで<code>aria-hidden=&quot;true&quot;</code>となるので別途指定はしていません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/Checkbox/Checkbox.tsx&initialpath=?refactor" style="width: 100%; height: 400px;"></iframe>
<pre class="language-tsx"><code class="language-tsx">// src/Checkbox/Checkbox.tsx

import * as React from 'react';
import CheckRoundedIcon from '@mui/icons-material/CheckRounded';
import './style.css';

type CheckboxProps = {
 checked: boolean;
 onChange: (event: React.ChangeEvent&lt;HTMLInputElement>) => void;
};

export const Checkbox: React.FC&lt;CheckboxProps> = ({ checked, onChange }) => {
 return (
 &lt;label className="checkbox">
 &lt;input type="checkbox" defaultChecked={checked} onChange={onChange} />
 &lt;span className="custom-checkbox">
 {checked &amp;&amp; &lt;CheckRoundedIcon fontSize="small" />}
 &lt;/span>
 &lt;span>ラベル&lt;/span>
 &lt;/label>
 );
};
</code></pre>
<pre class="language-css"><code class="language-css">/* src/Checkbox/Checkbox.tsx */

.checkbox {
 display: inline-flex;
 cursor: pointer;
 gap: 8px;
}

.checkbox input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

.checkbox .custom-checkbox {
 display: inline-block;
 width: 24px;
 height: 24px;
 border: 2px solid lightgray;
 border-radius: 4px;
 background-color: white;
 box-sizing: border-box;
}

.checkbox input[type='checkbox']:checked + .custom-checkbox {
 background-color: lightcoral;
}

.checkbox input[type='checkbox']:focus + .custom-checkbox {
 border-color: blue;
}
</code></pre>

アクセシビリティを考慮したカスタムなCheckboxを実装する方法です。

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップして便利なutil関数を実装します。

mswをラップした便利関数をつくる

この記事は <a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア Advent Calendar 2022</a> 7日目の記事です。
<h2 id="mswとは？">mswとは？</h2>
ネットワークレベルでAPIリクエストをモックできるAPIモックライブラリです。 
<a href="https://mswjs.io/" target="_blank">MSW – Seamless API mocking library for browser and Node | Mock Service Worker</a>
<h2 id="Node.js18とグローバルfetch()">Node.js18とグローバルfetch()</h2>
今までは<code>fetch()</code>を利用したフロントエンドのコードをNode.js環境でユニットテストを実行するには、グローバルスコープに<code>fetch()</code>が存在しないので、モックをしたりテスト実行時に<a href="https://github.com/node-fetch/node-fetch" target="_blank">node-fetch</a>をPolyfillとして適用してグローバルスコープに<code>fetch()</code>を生やすなどの対応をしていました。
Node.js18から新たにグローバルスコープのfetch APIがデフォルトで利用可能になり、モック対応をせずともテスト実行時に<code>fetch()</code>が利用できる状態になりました。
<h2 id="Node.js18環境でmswが動かない">Node.js18環境でmswが動かない</h2>
グローバルスコープでfetch APIが利用可能になったので、何の対応もせずそのままmswでテストを実行できると思い次のサンプルコードを実行したら、mswがAPIリクエストをインターセプトしてくれずリクエスエラーが発生して盛大にハマりました。 
<code>Caused by: Error: connect ECONNREFUSED ::1:3000</code>
当たり前に使えると思っていたので、無駄に時間を溶かしました。
<pre class="language-ts"><code class="language-ts">// User.tsx
export const User = () => {
 const [user, setUser] = useState&lt;User | null>(null);

 useEffect(() => {
 fetch("/user").then(async (res) => {
 const user = await res.json();
 setUser(user);
 });
 }, []);

 if (user == null) {
 return null;
 }

 return &lt;span>{user.name}&lt;/span>;
};

// User.test.tsx
import { rest } from "msw";
import { render, screen, waitFor } from "@testing-library/react";
import { server } from "../../test/server";

describe("User", () => {
 it("show user name", async () => {
 server.use(
 rest.get("/user", (_req, res, ctx) => {
 return res(ctx.json({ name: "taro" }));
 })
 );

 render(&lt;User />);
 await waitFor(() => expect(screen.getByText("taro")).toBeInTheDocument());
 });
});
</code></pre>
<h2 id="mswのインターセプターと対象モジュール">mswのインターセプターと対象モジュール</h2>
<a href="https://github.com/mswjs/interceptors" target="_blank">mswのインターセプター</a>は
<ul>
<li><code>http.get</code>/<code>http.request</code></li>
<li><code>https.get</code>/<code>https.request</code></li>
<li><code>XMLHttpRequest</code></li>
<li><code>window.fetch</code></li>
<li>その他のAPIクライアント(i.e. axios, request, node-fetch, supertest, etc.)</li>
</ul>
により発行されたリクエストを割り込み対象としてサポートしています。
Node.jsのfetch APIは標準の<code>http</code>モジュールを利用しておらず、<a href="https://github.com/nodejs/undici" target="_blank">undici</a>という別のモジュールによって実装されています。そのため、標準のfetch APIで発生したリクエストはmswのインターセプターの対象とならず今回のエラーが発生していました。
参考: <a href="https://shisama.hatenablog.com/entry/2022/04/20/011103" target="_blank">Node.js v18 の主な変更点</a>
<h2 id="node-fetchでfetch()を置き換える">node-fetchでfetch()を置き換える</h2>
現時点でmswを利用するには今まで通り<code>fetch()</code>をnode-fetchで置き換えてあげる必要があります。
<pre class="language-ts"><code class="language-ts">// test/setup.ts
import _fetch from "node-fetch";
import { server } from "./server";

// グローバルスコープのfetch()をnode-fetchで置き換える
// @ts-ignore
global.fetch = _fetch;

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// jest.config.js
module.exports = {
 setupFilesAfterEnv: ['./test/setup.ts'], 
}
</code></pre>
<h2 id="mswのFetch APIへの対応">mswのFetch APIへの対応</h2>
調べてみたら<a href="https://github.com/mswjs/interceptors/pull/283" target="_blank">標準のfetch APIに対応するPR</a>が既に作成されていたので、近い将来にはモック対応をせずにそのままmswが使えるかもです。

Node.js18の環境でmswを使った時にネットワークをインターセプトできない問題にハマった話です

Node.js18の環境でmswを使ったらハマった話

この記事は<a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア Advent Calendar 2022</a> 2日目の記事です。
<h2 id="結論">結論</h2>
<code>--max-warnings=0</code>をコミットフックで実行してあげることで問題は解消できます。
以下は実際にあった事例とコミットフックのサンプルコードです。
<h2 id="ESLintの警告が対応されずにプルリクが作成される問題">ESLintの警告が対応されずにプルリクが作成される問題</h2>
ESLintを導入していると、実装者がESLintの警告を対応し忘れたままプルリクを作成してしまうことが多々あります。GitHubではCIで警告が発生した時に自動でプルリクのコード差分に警告のメッセージをコメントとして残してくれますが、実装者は自分が作成したプルリクの差分を見ることをしないので自動コメントに気づかず、レビュアーが自動コメントと同じ箇所に同様のコメントをするという無駄な作業が発生します。
<img src="/images/posts/eslint-pr-warning/github-warning-comment.png" alt="githubの警告コメント" width="1082" height="690" />
<h2 id="レビューで指摘されずに警告が残ってしまう時もある">レビューで指摘されずに警告が残ってしまう時もある</h2>
レビュー時に気づいて削除できたら良いですが、レビュアーも指摘が漏れてそのままプルリクがマージされてしまい気づいたら数個の警告が残ったまま放置された状態になることもあります。GitHubでは差分の最後に警告コメントを雪だるま式に追記する形式になっているので、差分ページのスクロール量が増えて修正量が多いと錯覚を起こしたり小さなモヤっと感が開発者の中に溜まってしまいます。
こういった害はないけど少しモヤッとする状態は目に見えない形で開発者の精神衛生を悪くして、同じ対応を繰り返して無駄な作業工数を発生させてしまいます。
<ol>
<li>ESLintの警告の対応を忘れてマージされる</li>
<li>ESLintの警告がいくつか溜まった状態になる</li>
<li>気になってESLintの警告を全て削除する対応をする</li>
<li>1に戻る（以下ループ）</li>
</ol>
<h2 id="--max-warnings=0で警告をゼロにする">--max-warnings=0で警告をゼロにする</h2>
ESLintには最大の警告数を制限する<code>--max-warnings</code>というオプションがあり、<code>eslint --max-warnings=0</code>と実行をすることで、一つでも警告が存在するとESLintのチェックをエラーとすることができます。
コミットフックのタイミングで<code>--max-warnings=0</code>を指定してESLintを実行することで、警告が存在する場合のコミットを自動的に禁止にすることで、最終的に警告が存在する状態でプルリクが作られない仕組みを作ることができます。
実際にこの仕組みを導入するだけで、チーム内で定期的に発生していたプルリクでのESLintの警告は完全にゼロになりました。🎉
<pre class="language-json"><code class="language-json">"lint-staged": {
 "*.{js,jsx,ts,tsx}": [
 "eslint --max-warnings=0"
 ]
},
</code></pre>

GitHubでのプルリクのESlintで警告が残ったままになってしまう問題とその解決策です。

GitHubでのプルリクのESlintの警告をゼロにする

とあるフロントエンドエンジニアのブログ

記事一覧