DP Engineering Monday についてはこちらの記事をご覧ください。
DP Engineering Monday 第60回
DP Engineering Monday についてはこちらの記事をご覧ください。
ReactのuseDeferredValue by @takeharumikami
PostgreSQLのEXPLAINではどのようにコストを見積もっているのか - michio.me by @michio
DP Engineering Monday 2022年12月
DP Engineering Monday についてはこちらの記事をご覧ください。
第55回 (2022-12-19)
DP Engineering Monday 2022年11月
DP Engineering Monday についてはこちらの記事をご覧ください。
第50回 (2022-11-02)
- ChromeのDeveloper ToolがCSSが機能しない理由を教えてくれるようになったらしい by @michio0o
- Next.js 13のroutingについて by @takeharumikami
第51回 (2022-11-07)
DP Engineering Monday 2022年10月
DP Engineering Monday についてはこちらの記事をご覧ください。
第48回 (2022-10-03)
- CloudLoggingのLog AnalyticsがPublic Previewになってたので触ってみた by @michio0o
- Zoomサポートとのやりとり後日談 by @yaguchii__
- Cloud RunのMinimum number of instancesとRevisionsで8万円溶かした話 by oinume
第49回 (2022-10-24)
DP Engineering Monday 2022年9月
DP Engineering Monday についてはこちらの記事をご覧ください。
第45回 (2022-09-05)
- http/2 push の代替としての 103 Early Hints や Preloading by @1000ch
- Next.jsのホスティング先としてFirebaseは『かなりアリ』な選択肢になっている の記事について by @michio0o
- 副作用フックの利用法 by @takeharumikami
第46回 (2022-09-12)
第47回 (2022-09-26)
JavaScript/TypeScript の Lint ツールを XO で統一した
@1000ch (id:hc0001) です。掲題の通り、少し前にドクターズプライムの Frontend プロジェクトで使う lint ツールとして ESLint ではなく XO を使っていく方針に切り替えました。最近その振り返りを行ったので、その備忘録として文字に起こします。
経緯と課題
これまでは Create React App に付属する ESLint に加えてルールを少しカスタマイズして、それをいくつかのプロジェクトで使っていました。これにはいくつかの課題が存在していました。
- ESLint およびその周辺プラグインの依存関係を含めたバージョンアップをケアし続ける必要がある
- renovate や dependabot などを用いて（半）自動化できるものの、依存の数や大きさに応じて依然としてコストが高い
- ESLint のルールを中長期的にメンテナンスする必要がある
- 「このルールは採用する」「このルールは気にしない」など、妥当性の確認が難しく、往々にして好みが介在しやすい
- プロジェクト間で統一された lint ルールがなく、担当プロジェクトが変わった時のキャッチアップが難しい
これらの課題は、lint を適用するプロジェクトの数・大きさ・経年などに応じて、複合的に大きくなっていきます。ソースコードの、より効率的な品質維持のために lint ツールを切り替える提案をしました。
Frontend の lint 事情
JavaScript や TypeScript の lint には、複数の流派もとい選択肢が存在しています。古くから有名なのは Airbnb の JavaScript Style Guide に同梱される eslint-config-airbnb や GitHub の eslint-plugin-github などでしょうか。しかし、これらに関しても組織それぞれの好みを含めたルールが反映されています。また、大きな組織だからといって永続的にメンテナンスされる保証はなく、Google の eslint-config-google ですら放置されている状態からわかるように、それぞれの組織の事情はあれど、自分たちで維持・運用を続けていくのは相応のコストが伴います。
Go のように、公式で提供される有無を言わせないフォーマット機構があれば良いのですが、幸か不幸か Frontend 界隈にはそれがありません。「opinionated だけど、とりあえずこれに従ってください系」のフォーマッターという意味では Prettier がそうした立ち位置には近いと思いますが、文法の複雑さに応じて書き方に対しても lint が必要というところで ESLint と併せて適用することが望ましいでしょう。Prettier と ESLint のコンビネーションについては以下の記事がよくまとまっています。
- ESLint と Prettier の共存設定とその根拠について | blog.ojisan.io
- Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった | blog.ojisan.io
- ESLintとPrettierを併用するときの設定(eslint-plugin-prettier, eslint-config-prettier) - dackdive's blog
なぜ XO なのか
挙げた課題を大幅に改善してくれる、というか XO のコンセプトがまさにこれらの課題感から生まれています。
Opinionated but configurable ESLint wrapper with lots of goodies included. Enforces strict and readable code. Never discuss code style on a pull request again! No decision-making. No
.eslintrc to manage.It just works!GitHub - xojs/xo: ❤️ JavaScript/TypeScript linter (ESLint wrapper) with great defaults
これによって、XO のバージョンアップデートだけ気にすれば良く、XO のルールに従うことさえチームで握ればルールを運用する必要がない、そして XO を統一的に横断して導入することでキャッチアップのコストが小さくなります。
ルールについては sindresorhus 氏の opinionated であり、それも好みが分かれるといえばそれまでではありますが、個人的には納得感のあるルールが大半です。カスタマイズしないことに重きを置いたツールであり、カスタマイズしないことも今回の提案の一部ですが、何が何でも譲れないルールは上書きして良いでしょう（実際、ドクターズプライムでもタブインデントではなく 2 スペースインデントにしています）。ただ、ルールの上書きをし始めるとキリがないですし、中長期的な各種コストを減らすためにも限定的にすべきです。
XO そのものが継続的にメンテナンスされていくのかも気になるところですが、少なくとも現時点では活発にメンテナンスされています。まだメジャーバージョンがリリースされておらず、時折 breaking change が含まれるのが玉に瑕ですが、頻発しているわけでもなく xo --fix で自動的に修正できるので呑める我慢処として捉えています。
「ルールのカスタマイズを極小化したい」という点だけにフォーカスするならば、eslint-plugin-react の plugin:react/recommended や @typescript-eslint/eslint-plugin の plugin:@typescript-eslint/recommended といったように「ESLint の各種プラグインが推奨するプリセットルールのみを使用する」というアプローチもありそうです。しかし「どのプラグインを組み合わせて使うのか、あるいは ESLint 本体とのバージョン互換性はどうなのか」などに対応するコストが残ってきますし、プリセットのルールでは緩く、より実装のブレを減らそうとするともう少し強固なルールセットが必要そうに思います（ただし、後者に関しては状況や握り方次第だと思います）。
変更してみて
課題感だったパッケージやルールのアップデートに関するコストは、期待通り緩和されています。既存プロジェクトに対して、変更された lint ルールの適用は xo --fix でも自動で修正しきれないため現在進行中ですが、このコストは徐々になくなっていくでしょう。
DP Engineering Monday 2022年8月
DP Engineering Monday についてはこちらの記事をご覧ください。
第41回 (2022-08-01)
- A Philosophy of Software Design 6章 by @oinume
- Cloudflare WorkersでGoのHTTPサーバーを動かすライブラリを作った話 by @__syumai
- Datastore モードの Cloud Firestoreなのにトランザクションの制限が掛かったままになる by @issuy_
- BigQueryの権限管理についてメモ by @michio0o
第42回 (2022-08-08)
- HTML Priority Hints Help Etsy Ace Google Core Web Vitals by @1000ch
- dbt について by @michio0o
- PostgreSQL勉強中 part1 by @ron_4321
第43回 (2022-08-22)
第44回 (2022-08-29)
- Hasuraの更新系の振り返り by @issuy
- Chakra UI のカラーについて by @takeharumikami
- 社内のBigQuery権限申請と管理について by @michio0o
- Zoom APIを使ってみて設計する上での注意点 by @yaguchii__
DP Engineering Monday 2022年7月
DP Engineering Monday についてはこちらの記事をご覧ください。
第38回 (2022-07-04)
- AWS Summit Online 2022「医療業界に求められるセキュリティ対策と AWS が提供するソリューション」by @yaguchii__
- CSS の conic-gradients() を使った扇形にグラデーションしているボーダーの実装 by @1000ch
- 【しくじり先生】Studioのドメイン設定に時間がかかった話 by @issuy_
- CloudSQL のデータを BigQuery にエクスポートしたい話 by @michio0o
第39回 (2022-07-11)
- テストの時だけモックを入れたい by @tenntenn
- DBマイグレーションを含んだPRではtblsを使ってER図を自動更新する by @michio0o
- OpenTelemetryとhttptrace.ClientTraceを使ってHTTPリクエストのlatencyを可視化する - oinume journal by @oinume
- Next.js 12.2で、On-Demand ISRのstableがリリース by @takeharumikami
- Firebaseの匿名認証触って得た知見 @issuy_
第40回 (2022-07-25)
Skipped because of Tech Week
DP Engineering Monday 2022年6月
DP Engineering Monday についてはこちらの記事をご覧ください。
第34回 (2022-06-06)
- GraphQLのTypeScript / React の型の自動生成 by @takeharumikami
- Bubble Lesson: Using APIs and sending data to groups by @issuy_
- プロダクトのコンテンツ管理にmicroCMSを利用するという話 by @michio0o
- Web Standards Interop 2022（@1000ch） — TechFeed Conference 2022講演より - TechFeed by @1000ch
第35回 (2022-06-13)
第36回 (2022-06-20)
- GCP Serverless NEGをざっくりまとめた by @michio0o
- 分散トレーシングとOpenTelemetry by @oinume
- STUDIO x GTM でリダイレクト設定 by @issuy_
