機能開発を止めずに、500コンポーネント規模の Vue 3 移行を完了させた開発プロセス

IE サポートとは一体…スタディスト 開発本部 技術支援ユニットの笹木 (<a href="http://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。Microsoft による Internet Explorer (以下 IE) のサポート終了(2022/06)を 目前(執筆時点) とし、フロントエンドエンジニアの皆様はウッキウキの日々を過ごされていることでしょう。今回は、弊社の主要プロダクトである <a href="https://biz.teachme.jp/">Teachme Biz</a> における「IE サポート終了」が何を指しているのかを明らかにし、その範囲内で開発体験を最大限良くするために行った仕組み作りについてお話します。<h4>TL;DR</h4><ul><li>Teachme Biz は IE の「サポートを終了」するが、ビルドターゲットから IE を除外する「提供終了」をするわけではない</li><li>Vue 3 を採用したいが、そのためには IE への「提供終了」が必須</li><li>IE 用ブランチを切ってコードフリーズし、IE 用バンドルを凍結した</li><li>Rails で UserAgent を見て、モダンブラウザ用バンドルか IE 用バンドルのどちらかを埋め込むようにした</li><li>Teachme Biz において、IE が「推奨環境」でなく「動作環境」である事実から、サポート終了日を待たずに、先行してコードフリーズを実施した</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/671/0*oq48IULciT-ugwpA.png" /><figcaption>ありがとう そして さよなら</figcaption></figure><h4>IE と Teachme Biz</h4>昨年から今年にかけて、国内の多くの Web サービスから、 IE サポートの終了が告知されています。Teachme Biz もその例外に漏れず、<a href="https://help.teachme.jp/hc/ja/articles/4498453785241-Internet-Explorer11%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E7%B5%82%E4%BA%86%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B-2023%E5%B9%B42%E6%9C%8828%E6%97%A5">Internet Explorer11サポート終了に関するお知らせ</a> のアナウンスによって、2023年2月28日をもって、 IE サポートを終了することが決定しました。では Teachme Biz における「サポート終了」とはどういう意味でしょう。 同アナウンスでは、以下のように説明されています。<blockquote>現在のところ、IE11を経由したTeachme Bizへのアクセスの制御を行う予定はなく、サポート終了後即座に「IE11を用いてTeachme Bizにアクセスできなくなる」「特定の機能が使えなくなる」ことは予定しておりません。 (中略)</blockquote><blockquote>ただし、サポート対象外のブラウザであることから、すべての改善・不具合修正・新機能提供の対象からは除外されます。</blockquote>開発者にとって重要となるポイントは以下の2点です。<ul><li>IE に対する新たな改善、不具合修正、新機能提供を行う必要はない</li><li>IE でも既存の機能が、ある程度は動く状態にする</li></ul>「サポート終了」と聞いて、まずは前者に対して喜びを感じると思いますが、実は後者が意外にも厄介だったりします。これは「IE でのユーザー体験を積極的に悪くしてはいけない」ことになるため、 サポート終了≠ 提供終了 であるとも言えます。とはいえ、普通に開発している分にはこれで困ることはありません。新たなコードを書く際に IE を考慮しなくて良いと言うだけで万々歳です。しかし、後述の Vue 3 へのマイグレーションを考慮すると、これはあまり喜ばしいことではないのです。<h4>Vue 3 へのマイグレーションの足枷</h4>Teachme Biz のフロントエンドは、<a href="https://jp.vuejs.org/index.html">Vue.js</a> (以下 Vue) を採用した SPA です。現在は Vue の 2 系を使用していますが、Vue 3 では <a href="https://v3.ja.vuejs.org/api/composition-api.html">Composition API</a> による大規模開発への対応や、TypeScript による型安全性の向上、リアクティブシステムの刷新によるパフォーマンス改善などの、多くの恩恵を受けられるため、3 系へのマイグレーションを検討しています。しかし、Vue 3 は IE を一切サポートしていません。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*RqSic8k3LoHMOKml" /><figcaption>それはそう</figcaption></figure><a href="https://github.com/vuejs/rfcs/pull/294">Proposal for dropping ie11 support in Vue 3</a> によると、以下が大きな理由とされています。<blockquote>Vue 2’s reactivity system is based on ES5 getter/setters. Vue 3 leverages ES2015 Proxies for a more performant and complete reactivity system, which cannot be polyfilled in IE11. (中略) Vue 3’s Proxy-based reactivity system provides near complete language feature coverage. It is able to detect many operations that are impossible or impractical to intercept in ES5 (以下略)</blockquote>要約すると、Vue 3 がリアクティブシステムで採用する <a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Proxy">Proxy</a> は、<a href="https://babeljs.io/">Babel</a> + <a href="https://github.com/zloirock/core-js">core-js</a> のようなトランスパイルの仕組みを用いてもポリフィル(代替え) できないことを理由としています。<figure><img alt="" src="https://cdn-images-1.medium.com/max/743/1*ClcdV1voNI52XCbmtYF6kg.png" /><figcaption>Proxy は Babel+core-js でもダメだ</figcaption></figure>リアクティブシステムという Vue の根幹が動かない以上、Vue 3 アプリケーションを IE で動かすことは不可能です。必然的に、Teachme Biz で Vue 3 を採用することは IE への提供終了を意味します。では Vue 3 を諦めるのかと言うと、やはり前述の Vue 3 による恩恵は捨てがたいです。そうでなくても IE をビルドターゲットから除外すると、 バンドルサイズの大幅な削減に繋がることも確認しています。 (<a href="https://estimator.dev/">EStimator</a> 調べ)<figure><img alt="" src="https://cdn-images-1.medium.com/max/763/1*xoqlGa6MHTMrxCAyRaY9Ng.png" /><figcaption>Teachme Biz のあるページは 35% の削減余地がある</figcaption></figure>「IE でのサービス提供は続ける」「Vue 3 にマイグレーションする」一見すると両取りは不可能に見えますが、真の意味で IE サポートを終了し、開発体験を向上させるため、後述のアプローチによって、両取りを実現することにしました。<h4>IE 冷凍保存というアプローチ</h4>前述のとおり、Teachme Biz のフロントエンドは Vue.js による SPA です。しかし、完全な SPA というわけではなく、<a href="https://rubyonrails.org/">Ruby on Rails</a> で開発されたサーバサイドがファーストビューを描画し、そこに埋め込まれた &lt;script&gt; タグから SPA を開始するという構成になっています。デプロイ自体も同一リポジトリのサーバサイドとフロントエンドをまとめて行っており、以下のように <a href="https://circleci.com/ja/">CircleCI</a> にてビルドしたフロントエンドの成果物を <a href="https://circleci.com/ja/">AWS S3</a> にアップロードし、それを <a href="https://aws.amazon.com/jp/cloudfront/">CloudFront</a> から配信するための URL を、Rails がファーストビューでブラウザに伝えます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WSR673gIW61Yfs5uvB54Gg.png" /></figure>原則、 master ブランチへのマージをトリガーにデプロイワークフローを発火していますが、ここに ie/master という、IE用にコードフリーズしたブランチを追加します。社内ではこれを IE冷凍保存 と呼んでいます。ie/master ブランチでは、フロントエンドのビルド・デプロイのみを行い、従来通りに S3 に成果物をアップロードしておきます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*oQVmybakpNSYvdnuSjc4sQ.png" /></figure>それ以降に master ブランチの更新によってデプロイされた Rails は、通常のバンドルと、IE専用のバンドル2種類の所在(manifest) を知っているため、リクエストの UserAgent に基づいてバンドルを出し分けることができます。この仕組によって、IEなら凍結された ie/master ブランチのコードを、モダンブラウザなら master ブランチのコードを利用するようになります。これにより、master ブランチのコードが IE から参照されなくなるため、Vue 3 へのマイグレーションを master ブランチにマージできるようになります。また、IEのシェア率が限りなく0%に近くなってきたら、この仕組み自体を削除することで、シームレスに IE への提供を完全終了できます。<h4>IE のための品質担保</h4>前述のアプローチでは、IE ユーザーにとっては凍結済みのフロントエンドと最新のサーバサイドという、同一リポジトリなのにチグハグなバージョンを組み合わせたコードを利用することになるため、API の後方互換性が非常に重要になります。うっかり API の互換性を壊してしまったり、オペミスなどで IE 用バンドルのデプロイに失敗した場合に備えて、以下の仕組みも別途用意しています。<ul><li><a href="https://github.com/teamcapybara/capybara">Capybara</a> を用いた既存の E2E テストを、凍結したフロントエンドと最新のサーバサイドの組み合わせで実行し、既存機能が壊れていないことを担保</li><li><a href="https://www.cypress.io/">Cypress</a> を用いた E2E テストによって、本番環境でバンドルの出し分けが出来ていることを監視</li><li>ie/master ブランチのほかに、ie/develop ブランチのワークフローを用意し、緊急時にも同様の仕組みで修正を当てられるように</li><li>頼りがいがありすぎる QA チームに定期的に確認してもらう</li></ul><h4>でも IE サポート終了まで待ってられない</h4>Teachme Biz が IE のサポートを終了するのは 2023/02/28 であることは前述の通りで、IE冷凍保存の仕組みはそれ以降のための仕組みでした。とはいえ、Vue 3 を早く使いたいし、残り1年近くも待ちたくありません。実は Teachme Biz は現在、IE をサポート対象の「動作環境」としていますが、「推奨環境」ではないという違いがあります。<a href="https://biz.teachme.jp/function/#devices">対応デバイス・OS 推奨環境一覧</a> では、「動作環境」について、以下のように説明されています。<blockquote>一定の制約付きでご利用いただける環境です。</blockquote><blockquote>※動作環境は将来的にサポートを終了する可能性があります。備考欄および注意事項をご確認いただき、推奨環境での導入検討をお願いいたします</blockquote>事実、現在の Teachme Biz は、最新機能のほとんどを動作環境(≒IE) には提供しておりません。例えば年初にリリースされた <a href="http://Webブラウザ版で動画編集ができるように！動画の中間をカットする機能も追加されました">Web動画編集機能</a> が顕著な例です。<blockquote>※Internet Explorerでは利用できません。Internet Explorerの場合、これまで通り編集拡張プラグインが必要です。</blockquote>この事実を拡大解釈すると、現時点でIE用のコードを凍結してしまい、それを提供し続けるだけでも「動作環境」としての要件を満たせるのではないかと考えました。この提案を上長に行ったところ、IEユーザーが既に希少であること、現時点で Teachme Biz の主要機能を「動作環境」の範囲内で使えることが加味され、無事にいつでも凍結OKの許可が出ました。これによって、プロダクトとしての IE サポート終了を待たずに、開発者的には10ヶ月程度先行して、IE の提供終了を実現することが出来ました。<h4>まとめ</h4>本記事では、弊社プロダクトの Teachme Biz の 「IE サポート終了」が何を指すのかを明らかにし、それをふまえて開発体験を向上させるための「IE 提供終了」を実現したアプローチを紹介しました。記事公開時点で既に IE 用のコード凍結は完了しており、実際に UserAgent によるバンドルの出し分けが運用されています。これによって、IEサポート終了を待たずに、 Vue 3 の準備を開始することができたので、次回は 「Vue 3 にマイグレーションしました」の記事でお会いできることを楽しみにしています。<h4>最後に</h4>スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=abbd36882c61" width="1" height="1" alt=""><hr><a href="https://studist.tech/dropping-support-for-ie11-abbd36882c61">IE のサポートを終了せずに IE のサポートを終了した話</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

IE サポートとは一体…
スタディスト 開発本部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
Microsoft による Internet Explorer (以下 IE) のサポート終了(2022/06)を
目前(執筆時点) とし、フロントエンドエンジニアの皆様はウッキウキの日々を過ごされていることでしょう。
今回は、弊社の主要プロダクトである Teachme Biz における「IE サポート終了」が何を指しているのかを明らかにし、その範囲内で開発体験を最大限良くするために行った仕組み作りについてお話します。
TL;DR

Teachme Biz は IE の「サポートを終了」するが、ビルドターゲットから IE を除外する「提供終了」をするわけではない
Vue 3 を採用したいが、そのためには IE への「提供終了」が必須
IE 用ブランチを切ってコードフリーズし、IE 用バンドルを凍結した
Rails で UserAgent を見て、モダンブラウザ用バンドルか IE 用バンドルのどちらかを埋め込むようにした
Teachme Biz において、IE が「推奨環境」でなく「動作環境」である事実から、サポート終了日を待たずに、先行してコードフリーズを実施した
ありがとう そして さよなら
IE と Teachme Biz
昨年から今年にかけて、国内の多くの Web サービスから、 IE サポートの終了が告知されています。
Teachme Biz もその例外に漏れず、Internet Explorer11サポート終了に関するお知らせ のアナウンスによって、2023年2月28日をもって、 IE サポートを終了することが決定しました。
では Teachme Biz における「サポート終了」とはどういう意味でしょう。
同アナウンスでは、以下のように説明されています。
現在のところ、IE11を経由したTeachme Bizへのアクセスの制御を行う予定はなく、サポート終了後即座に「IE11を用いてTeachme Bizにアクセスできなくなる」「特定の機能が使えなくなる」ことは予定しておりません。
(中略)
ただし、サポート対象外のブラウザであることから、すべての改善・不具合修正・新機能提供の対象からは除外されます。
開発者にとって重要となるポイントは以下の2点です。

IE に対する新たな改善、不具合修正、新機能提供を行う必要はない
IE でも既存の機能が、ある程度は動く状態にする

「サポート終了」と聞いて、まずは前者に対して喜びを感じると思いますが、実は後者が意外にも厄介だったりします。
これは「IE でのユーザー体験を積極的に悪くしてはいけない」ことになるため、 サポート終了≠ 提供終了 であるとも言えます。
とはいえ、普通に開発している分にはこれで困ることはありません。新たなコードを書く際に IE を考慮しなくて良いと言うだけで万々歳です。しかし、後述の Vue 3 へのマイグレーションを考慮すると、これはあまり喜ばしいことではないのです。
Vue 3 へのマイグレーションの足枷
Teachme Biz のフロントエンドは、Vue.js (以下 Vue) を採用した SPA です。
現在は Vue の 2 系を使用していますが、Vue 3 では Composition API による大規模開発への対応や、TypeScript による型安全性の向上、リアクティブシステムの刷新によるパフォーマンス改善などの、多くの恩恵を受けられるため、3 系へのマイグレーションを検討しています。
しかし、Vue 3 は IE を一切サポートしていません。
それはそう
Proposal for dropping ie11 support in Vue 3 によると、以下が大きな理由とされています。
Vue 2’s reactivity system is based on ES5 getter/setters. Vue 3 leverages ES2015 Proxies for a more performant and complete reactivity system, which cannot be polyfilled in IE11.
(中略)
Vue 3’s Proxy-based reactivity system provides near complete language feature coverage. It is able to detect many operations that are impossible or impractical to intercept in ES5 (以下略)
要約すると、Vue 3 がリアクティブシステムで採用する Proxy は、Babel + core-js のようなトランスパイルの仕組みを用いてもポリフィル(代替え) できないことを理由としています。
Proxy は Babel+core-js でもダメだ
リアクティブシステムという Vue の根幹が動かない以上、Vue 3 アプリケーションを IE で動かすことは不可能です。必然的に、Teachme Biz で Vue 3 を採用することは IE への提供終了を意味します。
では Vue 3 を諦めるのかと言うと、やはり前述の Vue 3 による恩恵は捨てがたいです。そうでなくても IE をビルドターゲットから除外すると、
バンドルサイズの大幅な削減に繋がることも確認しています。
(EStimator 調べ)
Teachme Biz のあるページは 35% の削減余地がある
「IE でのサービス提供は続ける」「Vue 3 にマイグレーションする」
一見すると両取りは不可能に見えますが、真の意味で IE サポートを終了し、開発体験を向上させるため、後述のアプローチによって、両取りを実現することにしました。
IE 冷凍保存というアプローチ
前述のとおり、Teachme Biz のフロントエンドは Vue.js による SPA です。
しかし、完全な SPA というわけではなく、Ruby on Rails で開発されたサーバサイドがファーストビューを描画し、そこに埋め込まれた <script> タグから SPA を開始するという構成になっています。
デプロイ自体も同一リポジトリのサーバサイドとフロントエンドをまとめて行っており、以下のように CircleCI にてビルドしたフロントエンドの成果物を AWS S3 にアップロードし、それを CloudFront から配信するための URL を、Rails がファーストビューでブラウザに伝えます。

原則、 master ブランチへのマージをトリガーにデプロイワークフローを発火していますが、ここに ie/master という、IE用にコードフリーズしたブランチを追加します。社内ではこれを IE冷凍保存 と呼んでいます。
ie/master ブランチでは、フロントエンドのビルド・デプロイのみを行い、従来通りに S3 に成果物をアップロードしておきます。

それ以降に master ブランチの更新によってデプロイされた Rails は、通常のバンドルと、IE専用のバンドル2種類の所在(manifest) を知っているため、リクエストの UserAgent に基づいてバンドルを出し分けることができます。
この仕組によって、IEなら凍結された ie/master ブランチのコードを、モダンブラウザなら master ブランチのコードを利用するようになります。これにより、master ブランチのコードが IE から参照されなくなるため、Vue 3 へのマイグレーションを master ブランチにマージできるようになります。
また、IEのシェア率が限りなく0%に近くなってきたら、この仕組み自体を削除することで、シームレスに IE への提供を完全終了できます。
IE のための品質担保
前述のアプローチでは、IE ユーザーにとっては凍結済みのフロントエンドと最新のサーバサイドという、同一リポジトリなのにチグハグなバージョンを組み合わせたコードを利用することになるため、API の後方互換性が非常に重要になります。
うっかり API の互換性を壊してしまったり、オペミスなどで IE 用バンドルのデプロイに失敗した場合に備えて、以下の仕組みも別途用意しています。

Capybara を用いた既存の E2E テストを、凍結したフロントエンドと最新のサーバサイドの組み合わせで実行し、既存機能が壊れていないことを担保
Cypress を用いた E2E テストによって、本番環境でバンドルの出し分けが出来ていることを監視
ie/master ブランチのほかに、ie/develop ブランチのワークフローを用意し、緊急時にも同様の仕組みで修正を当てられるように
頼りがいがありすぎる QA チームに定期的に確認してもらう

でも IE サポート終了まで待ってられない
Teachme Biz が IE のサポートを終了するのは 2023/02/28 であることは前述の通りで、IE冷凍保存の仕組みはそれ以降のための仕組みでした。
とはいえ、Vue 3 を早く使いたいし、残り1年近くも待ちたくありません。
実は Teachme Biz は現在、IE をサポート対象の「動作環境」としていますが、「推奨環境」ではないという違いがあります。
対応デバイス・OS 推奨環境一覧 では、「動作環境」について、以下のように説明されています。
一定の制約付きでご利用いただける環境です。
※動作環境は将来的にサポートを終了する可能性があります。備考欄および注意事項をご確認いただき、推奨環境での導入検討をお願いいたします
事実、現在の Teachme Biz は、最新機能のほとんどを動作環境(≒IE) には提供しておりません。
例えば年初にリリースされた Web動画編集機能 が顕著な例です。
※Internet Explorerでは利用できません。Internet Explorerの場合、これまで通り編集拡張プラグインが必要です。
この事実を拡大解釈すると、現時点でIE用のコードを凍結してしまい、それを提供し続けるだけでも「動作環境」としての要件を満たせるのではないかと考えました。
この提案を上長に行ったところ、IEユーザーが既に希少であること、現時点で Teachme Biz の主要機能を「動作環境」の範囲内で使えることが加味され、無事にいつでも凍結OKの許可が出ました。
これによって、プロダクトとしての IE サポート終了を待たずに、開発者的には10ヶ月程度先行して、IE の提供終了を実現することが出来ました。
まとめ
本記事では、弊社プロダクトの Teachme Biz の 「IE サポート終了」が何を指すのかを明らかにし、それをふまえて開発体験を向上させるための「IE 提供終了」を実現したアプローチを紹介しました。
記事公開時点で既に IE 用のコード凍結は完了しており、実際に UserAgent によるバンドルの出し分けが運用されています。
これによって、IEサポート終了を待たずに、 Vue 3 の準備を開始することができたので、次回は 「Vue 3 にマイグレーションしました」の記事でお会いできることを楽しみにしています。
最後に
スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！
株式会社スタディストの会社情報 - Wantedly

IE のサポートを終了せずに IE のサポートを終了した話 was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

IE のサポートを終了せずに IE のサポートを終了した話

<h3>ESLint の設定を ESLint でテストする</h3><a href="https://eslint.org/">ESLint</a> の設定、見直せてますか？スタディスト 開発部 技術支援ユニットの笹木 (<a href="http://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。今回は ESLint の設定を ESLint でテストする という一見奇妙な表題で、 ESLint 設定周りの課題を解決したお話をします。<figure><img alt="" src="https://cdn-images-1.medium.com/max/866/0*cwTobRLSpUATTTzN.jpg" /><figcaption><a href="https://eslint.org/">https://eslint.org/</a></figcaption></figure><h3>課題感</h3>ESLint には標準で多数のルールが組み込まれており、それぞれに詳細なオプションが用意されています。それに加えて、豊富なサードパーティ製のルールや、設定を継承する仕組み(extends) まで揃っているため、設定パターンは無限にあると言っても良いでしょう。コードベースが小さいうちは、 eslint:recommended のような推奨設定を継承するだけで、すぐにベストプラクティスを実践することができます。しかし、Vue や TypeScript といった技術構成や、Prettier などのツールとの兼ね合い、そして既存コードの傾向や歴史的経緯といった理由から、やむを得ず設定が複雑化していくことも往々にしてあると思います。弊社でもその傾向が年々強まり、気づけば ESLint の設定は 100 行を超えていました。設定が複雑化した ESLint を使用していると、以下のような課題が生まれてきました。<ul><li>設定作業時、設定が意図通りに反映されているかの検証が難しい</li><li>設定変更時の影響範囲が読みづらい</li><li>結局どのようなルールが適用されているのかわかりづらい</li><li>ESLint やプラグインのバージョンアップで挙動が変わるか確認できない</li></ul>いずれも自動テストという、アプリケーションコードなら当然ある仕組みが存在しないことによるものであると考えられます。<h3>解決策の提案</h3>自動テストがないなら作ればいいじゃない。テストといっても、Jest を使った単体テストのような味気ないものではありません。今回は、ESLint が意図通りに振る舞うかを検証するためのコードを作成し、それを ESLint でテストするという方式にしました。つまりどういうことか、以下がそのサンプルです。<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/ca1bd72b3c3a310b59e4f57c07afc535/href">https://medium.com/media/ca1bd72b3c3a310b59e4f57c07afc535/href</a></iframe>上記コードは、ESLint が以下の意図通りに動いていることを担保します。<ul><li>推奨設定を継承できていること (3行目)</li><li>推奨設定にない追加ルールを有効化していること (7行目)</li><li>推奨設定にある一部ルールを無効化していること (11行目)</li><li>推奨設定にある一部ルールのオプションが変更されてること (15行目)</li></ul>このコードは見ての通り、違反コードの上に eslint-disable-next-line があるため、コード上は違反でも ESLint はエラーを検知しません。では、これでどうやって設定を担保できるのか、その秘密は <a href="https://eslint.org/docs/user-guide/command-line-interface#--report-unused-disable-directives">reportUnusedDisableDirectives</a> というオプションにあります。<pre>&quot;reportUnusedDisableDirectives&quot;: true</pre>これは、検知する違反が存在しないのに eslint-disable-next-line など無効化するコメントがあった場合に、違反として検知とするオプションです。これを踏まえてもう一度サンプルコードの一部を見てみます。<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/7c10ba754790e746d0984fb2875a063d/href">https://medium.com/media/7c10ba754790e746d0984fb2875a063d/href</a></iframe>var の使用は禁止されているので、3行目は本来エラーになりますが、 eslint-disable-next-line no-varによって無効化されています。ここで、うっかり no-var をオフにするミスをしたとします。<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/f0f78b360fd37cb69ae0a923c844e468/href">https://medium.com/media/f0f78b360fd37cb69ae0a923c844e468/href</a></iframe>これによって var の使用が許可され、eslint-disable-next-line no-var は不要となり、reportUnusedDisableDirectivesによって以下のエラーが出るようになります。<pre>6:1 warning Unused eslint-disable directive (no problems were reported from &#39;no-var&#39;)</pre>見事、 no-varが有効であることを意図しているのに無効になっていることを検知しました。このファイルを、 CI でアプリケーションコードと一緒に ESLint でチェックするだけで、既存の CI の仕組みにそのまま乗っかることができます。ここでは JavaScript (sample.js)を例にしましたが、同様に TypeScript, Vue のファイル(sample.ts sample.vue )も用意し、それぞれの拡張子に対する ESLint 設定の意図をコード化すれば完成です。<h3>解決策を導入してみて</h3>解決策を導入することで、当初持っていた課題を解決できました。<ul><li>設定作業時、設定が意図通りに反映されているかの検証が難しい → 意図を表現したテストコードを書けば OK</li><li>設定変更時の影響範囲が読みづらい → テストが通るか見れば OK</li><li>結局どのようなルールが適用されているのかわかりづらい → テストコードを見れば OK</li><li>ESLint やプラグインのバージョンアップで挙動が変わるか確認できない → テストが通れば OK</li></ul>また、ESLint の実例をテストコード化することで、ルールの背景はコメントで、具体例はコードで説明できるようになり、ルールの良し悪しの議論がしやすくなりました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/899/0*13cx0BmdMoXvA00f.jpg" /><figcaption>ルールの背景と実例を元にした議論の事例</figcaption></figure>同様に、新たにルールを追加・改修した際も、PR にテストコードを含めることで、何が変わるのかをレビュアーに説明しやすくなりました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/886/1*9b8demOVYrWwOS4ZdDEaHA.png" /><figcaption>Vue コンポーネントで emits フィールドを宣言せずに emit することを禁止したルールを追加した例</figcaption></figure><h3>最後に</h3>本記事では、ESLint の設定が複雑化した際に生じる様々な課題を、ESLint 自身を用いて解決した事例を紹介しました。導入から3ヶ月近くが経過したので、ふりかえりも兼ねて記事にしましたが、特にこれ自体のメンテコストを感じることなく、充分な恩恵を得られています。スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=8d03870a23d9" width="1" height="1" alt=""><hr><a href="https://studist.tech/test-eslint-config-by-eslint-8d03870a23d9">ESLint の設定を ESLint でチェックする</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESLint の設定を ESLint でテストする
ESLint の設定、見直せてますか？
スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
今回は ESLint の設定を ESLint でテストする という一見奇妙な表題で、 ESLint 設定周りの課題を解決したお話をします。
https://eslint.org/
課題感
ESLint には標準で多数のルールが組み込まれており、それぞれに詳細なオプションが用意されています。それに加えて、豊富なサードパーティ製のルールや、設定を継承する仕組み(extends) まで揃っているため、設定パターンは無限にあると言っても良いでしょう。
コードベースが小さいうちは、 eslint:recommended のような推奨設定を継承するだけで、すぐにベストプラクティスを実践することができます。
しかし、Vue や TypeScript といった技術構成や、Prettier などのツールとの兼ね合い、そして既存コードの傾向や歴史的経緯といった理由から、やむを得ず設定が複雑化していくことも往々にしてあると思います。
弊社でもその傾向が年々強まり、気づけば ESLint の設定は 100 行を超えていました。
設定が複雑化した ESLint を使用していると、以下のような課題が生まれてきました。

設定作業時、設定が意図通りに反映されているかの検証が難しい
設定変更時の影響範囲が読みづらい
結局どのようなルールが適用されているのかわかりづらい
ESLint やプラグインのバージョンアップで挙動が変わるか確認できない

いずれも自動テストという、アプリケーションコードなら当然ある仕組みが存在しないことによるものであると考えられます。
解決策の提案
自動テストがないなら作ればいいじゃない。
テストといっても、Jest を使った単体テストのような味気ないものではありません。今回は、ESLint が意図通りに振る舞うかを検証するためのコードを作成し、それを ESLint でテストするという方式にしました。
つまりどういうことか、以下がそのサンプルです。
https://medium.com/media/ca1bd72b3c3a310b59e4f57c07afc535/href
上記コードは、ESLint が以下の意図通りに動いていることを担保します。

推奨設定を継承できていること (3行目)
推奨設定にない追加ルールを有効化していること (7行目)
推奨設定にある一部ルールを無効化していること (11行目)
推奨設定にある一部ルールのオプションが変更されてること (15行目)

このコードは見ての通り、違反コードの上に eslint-disable-next-line があるため、コード上は違反でも ESLint はエラーを検知しません。
では、これでどうやって設定を担保できるのか、その秘密は reportUnusedDisableDirectives というオプションにあります。
"reportUnusedDisableDirectives": true
これは、検知する違反が存在しないのに eslint-disable-next-line など無効化するコメントがあった場合に、違反として検知とするオプションです。
これを踏まえてもう一度サンプルコードの一部を見てみます。
https://medium.com/media/7c10ba754790e746d0984fb2875a063d/href
var の使用は禁止されているので、3行目は本来エラーになりますが、 eslint-disable-next-line no-varによって無効化されています。
ここで、うっかり no-var をオフにするミスをしたとします。
https://medium.com/media/f0f78b360fd37cb69ae0a923c844e468/href
これによって var の使用が許可され、eslint-disable-next-line no-var は不要となり、reportUnusedDisableDirectivesによって以下のエラーが出るようになります。
6:1  warning  Unused eslint-disable directive (no problems were reported from 'no-var')
見事、 no-varが有効であることを意図しているのに無効になっていることを検知しました。
このファイルを、 CI でアプリケーションコードと一緒に ESLint でチェックするだけで、既存の CI の仕組みにそのまま乗っかることができます。
ここでは JavaScript (sample.js)を例にしましたが、同様に TypeScript, Vue のファイル(sample.ts sample.vue )も用意し、それぞれの拡張子に対する ESLint 設定の意図をコード化すれば完成です。
解決策を導入してみて
解決策を導入することで、当初持っていた課題を解決できました。

設定作業時、設定が意図通りに反映されているかの検証が難しい
→ 意図を表現したテストコードを書けば OK
設定変更時の影響範囲が読みづらい
→ テストが通るか見れば OK
結局どのようなルールが適用されているのかわかりづらい
→ テストコードを見れば OK
ESLint やプラグインのバージョンアップで挙動が変わるか確認できない
→ テストが通れば OK

また、ESLint の実例をテストコード化することで、ルールの背景はコメントで、具体例はコードで説明できるようになり、ルールの良し悪しの議論がしやすくなりました。
ルールの背景と実例を元にした議論の事例
同様に、新たにルールを追加・改修した際も、PR にテストコードを含めることで、何が変わるのかをレビュアーに説明しやすくなりました。
Vue コンポーネントで emits フィールドを宣言せずに emit することを禁止したルールを追加した例
最後に
本記事では、ESLint の設定が複雑化した際に生じる様々な課題を、ESLint 自身を用いて解決した事例を紹介しました。
導入から3ヶ月近くが経過したので、ふりかえりも兼ねて記事にしましたが、特にこれ自体のメンテコストを感じることなく、充分な恩恵を得られています。
スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！
株式会社スタディストの会社情報 - Wantedly

ESLint の設定を ESLint でチェックする was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESLint の設定を ESLint でチェックする

<h3>Rails と密なフロントエンド開発環境を分離するための3つの工夫</h3><a href="https://adventar.org/calendars/6222">スタディスト開発ブログ Advent Calendar 2021</a>の20日目の記事です。本日は技術支援ユニットの笹木(@s_sasaki_0529) が、開発環境で Rails を立ち上げずに、リモートAPIサーバに接続してフロントエンド開発を行えるようにした話をします。<h3>TL;DR</h3><ul><li>SPA なのに Rails と Vue が密になってるアプリケーションを開発してる</li><li>せめて開発環境ぐらいはフロントエンド単体で開発できる状態にしたい</li><li>様々な問題を対処し、理想のフロントエンド開発環境を実現した</li></ul><h4>Teachme Biz の現状のアーキテクチャ</h4>スタディストが開発・運用する、マニュアル作成・共有システム <a href="https://biz.teachme.jp/">Teachme Biz</a> は、<a href="https://jp.vuejs.org/index.html">Vue.js</a> (≠ <a href="https://nuxtjs.org/">Nuxt.js</a>) によるフロントエンドと、<a href="https://railsguides.jp/">Ruby on Rails</a> によるバックエンドで構成されています。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*KfjgbUO2w34eUKq6VrlTNQ.png" /><figcaption>Teachme Biz (Web) の大雑把な構成図</figcaption></figure>上図だけ見ると、Rails が API サーバーに徹しており、非常に簡素で疎結合に見えます。しかし、Teachme Biz は元々、 SPA ではなかったところを、API の追加やフロントエンドのリプレイスによって SPA 化した経緯があります(以下記事参照)<a href="https://studist.tech/rails-vuejs-select-framework-103458169f70">Rails + Vue.jsでUIリニューアルしてみた(フロントフレームワーク選定編)</a>そのため、現在でも非SPA時代の名残のような責務を Rails が担い続けている状態になっています。具体的には、ブラウザからの初回リクエストを Rails がハンドリングするため、API 以外にも以下のような責務を担っています。<ul><li>リクエストパス、セッションに基づくリダイレクト操作</li><li>meta タグの注入(SEO用途など)</li><li>CSRF トークンの DOM への注入</li><li>リクエストパスに基づいた script が注入 されたHTML のレンダリング</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Xb7EP_rLZgpCEVsdw7FP4A.png" /><figcaption>Rails が持つ API 以外の責務は想像以上に大きい</figcaption></figure>上図の通り、SPA 開始用の HTML を Rails の View(erb)でレンダリングしています。つまり、Rails がなければフロントエンドを開始することすら出来ないということです。この状態を、本記事では Rails と Vue が密であると定義します。<h4>現状のフロントエンド開発環境の課題</h4>前述のとおり、Teachme Biz は、 Rails と Vue が密な構成になっています。これはユーザー体験の向上やSEOの面では有効に機能しており、これ自体が大きな問題であるとは言えません (とはいえ、もう少し疎にしたい)では開発環境はどうでしょうか？アーキテクチャ上は Rails と Vue が密であるとはいえ、アプリケーションの大部分は SPA であり、フロントエンドとバックエンドが REST API でのみ繋いでいるのも事実です。しかし、この構成である以上、フロントエンドのみの開発をする場合も、Rails を含めたバックエンドの開発環境を構築する必要があります。バックエンドの開発環境が必須であると、フロントエンドの開発をする上で以下のような課題が生まれます。<ul><li><a href="https://www.docker.com/">Docker</a> /<a href="https://docs.docker.jp/compose/toc.html"> Docker Compose</a> での環境構築の敷居が高い (特にデザイナ)</li><li><a href="https://docker-sync.readthedocs.io/en/latest/">docker-sync</a> によるホストとゲストの同期が遅く、トラブルも多い</li><li>サーバを動かすためのリソースの消費が激しく、応答も遅くなりがち</li><li>マイクロサービスに関わる画面をイジる場合は、さらに環境構築が必要</li><li>検証に使用するデータを逐一ローカルに用意する必要がある</li></ul>これらの課題を解消すれば、フロントエンドの開発をさらに効率化できる可能性があることに気づきました。<h4>現状のフロントエンド開発環境の構成</h4>フロントエンドの開発用サーバとして、 <a href="https://webpack.js.org/configuration/dev-server/">webpack-dev-server</a> が動いています。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WUy3lBZ5-6bbCYcm9n3IcA.png" /><figcaption>ブラウザと Rails それぞれ支援する webpack-dev-server</figcaption></figure>webpack-dev-server は、 <a href="https://webpack.js.org/">webpack</a> のビルド結果をオンメモリで持ちつつ、 <a href="https://developer.mozilla.org/ja/docs/Web/API/WebSockets_API">WebSockets</a>を通じて、差分ビルド結果をブラウザに動的に読み込ませる役割を持ちます。Teachme Biz のアーキテクチャ上、Rails が最新の JavaScript パスを知る必要があるため、Rails も webpack-dev-server にリクエストする、やや特殊な構成となっています。この構成をベースに、理想のフロントエンド開発環境(以下、新フロント開発環境)を要件を決め、実現していきます。<h4>新フロント開発環境</h4>前述の課題感を解決するため、ここでは、以下を理想のフロントエンド開発環境とします。<ul><li>Docker を使わずとも、ホストマシン(≒Mac) だけで立ち上がる</li><li>Rails を含むバックエンドサーバを立ち上げる必要がない</li><li>任意のリモート環境の API を利用できる</li></ul>また、上記を実現する上で、以下は守るべき大前提とします。<ul><li>開発環境のためだけのアプリケーションコードを書かない</li><li>環境差異を作らない (≒ production と staging で振る舞いを分岐しない)</li><li>セキュリティを緩めるような変更をしない</li></ul>以下のようなイメージで、フロントエンド開発環境のみで任意のサーバのAPI を呼び出せるようにします。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*q4A4RSF3eCRubkF43xHs1A.png" /><figcaption>新フロント開発環境のイメージ</figcaption></figure><h4>理想を阻む３種の壁</h4>新フロント開発環境を、現状のアーキテクチャで実現するためには、解決すべき3つの問題がありました。<ul><li>クロスオリジンでの XHR が許可されていない</li><li>CSRF トークンの検証を突破できない</li><li>SPA を開始するための HTML ファイルが手に入らない</li></ul>それぞれについて、どういう問題なのかを含め、解決策をお話します。<h4>壁１: クロスオリジンでの XHR が許可されていない</h4>開発環境上の Rails (Same Origin) でなく、リモートの Rails (Cross Origin) の API を呼び出すためには、<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/CORS">CORS</a> 制約を回避する必要があります。<figure><img alt="" src="https://cdn-images-1.medium.com/max/678/1*G8qgMKF3M5G8DqhStPWxag.png" /><figcaption>Webエンジニアが大好きとされる CORS エラー</figcaption></figure>この問題は、レスポンスの <a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Access-Control-Allow-Origin">Access-Control-Allow-Origin</a> ヘッダーなどで、オリジンを許可することで回避することが可能です。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*tbt3LlqvgbUTSCeC" /><figcaption>Rails(Rack) での CORS設定の例</figcaption></figure>しかし、この対応ではアプリケーションへの脆弱性が生まれないかを慎重に検討する必要があるため、前提条件を満たせるとは言えません。また、検証環境のみ対応することで、本番環境のセキュリティを維持することはできますが、今度は環境差異が生じるため、これも前提条件に反します。これではクロスオリジンを許可したいけどクロスオリジンを許可したくないという二律背反になります。ではどうするか、そもそもクロスオリジンリクエストにならなければ良いのでは？ということで、 webpack-dev-server に、API リクエストをプロキシしてもらう構成にしました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*PKF0HagiWcoEKXotJa47iQ.png" /><figcaption>プロキシによって SameOrigin にみせた CrossOrigin を実現</figcaption></figure>これは webpack-dev-server の <a href="https://webpack.js.org/configuration/dev-server/#devserverproxy">proxy オプション</a>で実現可能です。<figure><img alt="" src="https://cdn-images-1.medium.com/max/778/1*0BAZ9riug38lPsTyv8WOZA.png" /><figcaption>target を書き換えれば任意の環境にリクエストできる</figcaption></figure>この方法の利点は、ブラウザから見たら SameOrigin にリクエストしているつもりなので、アプリケーションコードの改修が不要という点です。これにより、 webpack-dev-server の設定変更のみで、クロスオリジンリクエストができるようになりました。<h4>壁２: CSRFトークン の検証を突破できない</h4>２つ目の壁は、現状では Rails が View(erb) で埋め込む CSRFトークン の取得が出来ないという問題です。CSRF トークンとは、<a href="https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA">CSRF</a> 攻撃への対策として、Rails が用意している <a href="https://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html#method-i-protect_from_forgery">protect_from_forgery</a> での検証に使用されるトークンのことです。この仕組みが有効な場合、CSRF攻撃の余地があるリクエストには、事前に発行されたトークンを含まなければブロックされるようになります。Teachme Biz が元々非SPA であった経緯もあり、現状ではこの CSRF トークンが、Rails の View(erb) を通じて DOM に埋め込まれるため、フロントエンドはそれを取得してリクエストに含む必要があります。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IgEDBns96vgg5eRRPKZ1_Q.png" /><figcaption>現状の CSRFトークンの受け渡しの流れ</figcaption></figure>当然ながら上記の方法は、Rails が HTML を生成することを前提としているため、API サーバに徹してもらう理想の開発環境では実現できません。とはいえ、この問題は歴史的経緯に過ぎない部分もあるため、思い切ってアプリケーションコードを改修し、ログイン後に呼ばれる API のレスポンスにトークンを含んでもらう方式を採用します。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IFVTJEDs6XwzNBRf0JZIdA.png" /><figcaption>理想の開発環境のための改修</figcaption></figure>ちなみに該当の API を叩くまでに、CSRF トークンを必要とする API リクエストを必要としなかったことは、偶然にして幸いでした。<h4>壁３: SPA を開始するための HTML ファイルが手に入らない</h4>API の提供を除くと、現状の Rails の最大の責務は、SPA を開始するための HTML のレンダリングとその配信でした。Rails なしでこれを実現するために、Rails に代わって、webpack-dev-server に HTML を生成、配信する責務を持たせます。Teachme Biz では、webpack を用いて、機能の分類に応じた3種類のエントリーファイルを、ビルド時に生成します。<figure><img alt="" src="https://cdn-images-1.medium.com/max/994/1*OaAvRcXJqmp1ktgiOiV-kg.png" /><figcaption>webpack.config.js</figcaption></figure>エントリーファイルが3種類あるため、それぞれを読み込む script タグを注入した HTML ファイルが3種類必要になります。これは webpack プラグインの一種である、<a href="https://github.com/jantimon/html-webpack-plugin">html-webpack-plugin</a> を使用し、ビルドごとに最新のハッシュがついた JS ファイルを読み込む HTML ファイルを出力します。<figure><img alt="" src="https://cdn-images-1.medium.com/max/978/1*BxitLfe05wDNyQR7B1MqOw.png" /><figcaption>webpack.config.js</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*diFnAo_AvcehnVarIgRRSw.png" /><figcaption>生成された HTML ファイル例</figcaption></figure>これで３種類のエントリーファイルに対応する、login.html / groups.html / manuals.html の３種類の HTML ファイルが出揃いました。次は、ブラウザの初回リクエスト時のパスに応じた、適切なHTMLファイルを返す仕組みを用意します。これについては、 webpack-dev-server の <a href="https://webpack.js.org/configuration/dev-server/#devserverhistoryapifallback">historyApiFallback</a> オプションを活用します。これは、webpack-dev-server が保持していないファイルのリクエストが届いた際、どのようにフォールバックするかを決定するオプションです。本来は 404ページへのリダイレクトなどに使うものと思われますが、これを活用して、SPA 開始前の論理パスから、生成された HTML ファイルの物理パスへの変換を実現します。<figure><img alt="" src="https://cdn-images-1.medium.com/max/820/1*Q08gYijlVUS1817XrJA3uw.png" /><figcaption>webpack.config.js (細かい正規表現は調整中)</figcaption></figure>これによって、初回リクエスト時のパスに応じた、SPA 開始用の HTML を webpack-dev-server から手に入れられるようになり、API 以外は Rails に頼る必要がなくなりました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*-z_qqxZDRMwkVkcvBGKkeQ.png" /><figcaption>初回リクエスト時の webpack-dev-server との関係</figcaption></figure><h4>全ての壁を突破して</h4>これで、新フロント開発環境を阻む３つの壁を突破出来ました。クロスオリジンでの XHR が許可されていない→ webpack-dev-server でプロキシすることで解決CSRFトークン の検証を突破できない→ DOM 経由でなくAPI でトークンを受け取れるようし解決SPA を開始するための HTML ファイルが手に入らない→ webpack, webpack-dev-server で HTML を生成し、リクエストの論理パスに応じて返すことで解決ここまでの工夫を経て、(わかりづらいですが)以下のように、開発環境のフロントエンドから、リモート環境(∋本番環境) の API を利用できるようになりました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cXsrEzGoxCVGy9oJ-kFgTA.png" /><figcaption>localhost:3035 だけど本番環境のマニュアル一覧が取得できている</figcaption></figure>新フロント開発環境では引き続き webpack-dev-server が動いているため、ホットリロードなどの従来の仕組みはそのまま、バックエンドの環境は一切用意せずに開発できるようになりました。<h4>まとめと今後の展望</h4>本記事では、Rails と Vue が密結合になっているアプリケーションを、フロントエンド単体で開発できるように分離した、新フロント開発環境を構築しました。もちろんアプリケーション自体の Rails と Vue の密結合は変わっていないため、境界部分の開発、検証用に従来の開発環境も残す形となりましたが、SPA 部分に限定した開発を行う場合は使い分けることで、開発効率を飛躍的に高めることが出来たと思います。今後は webpack-dev-server に持たせている責務を <a href="https://vitejs.dev/">Vite</a> に載せかえることでさらなる高速化を図ったり、開発環境に閉じない、プロダクト自体の疎結合化を進め、スケールやデプロイしやすくすることも考えています。<h4>We are hiring.</h4>スタディスト開発部では、こういった開発基盤の改善にも力を入れられる土壌が整っています。本記事を読み、少しでもスタディスト開発部が気になった方は、まずはお気軽にご連絡いただけると嬉しいです。<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f8acdfcc0d16" width="1" height="1" alt=""><hr><a href="https://studist.tech/new-dx-for-frontend-f8acdfcc0d16">Rails と密なフロントエンドの開発環境を分離するための3つの工夫</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rails と密なフロントエンド開発環境を分離するための3つの工夫
スタディスト開発ブログ Advent Calendar 2021の20日目の記事です。本日は技術支援ユニットの笹木(@s_sasaki_0529) が、開発環境で Rails を立ち上げずに、リモートAPIサーバに接続してフロントエンド開発を行えるようにした話をします。
TL;DR

SPA なのに Rails と Vue が密になってるアプリケーションを開発してる
せめて開発環境ぐらいはフロントエンド単体で開発できる状態にしたい
様々な問題を対処し、理想のフロントエンド開発環境を実現した

Teachme Biz の現状のアーキテクチャ
スタディストが開発・運用する、マニュアル作成・共有システム Teachme Biz は、Vue.js (≠ Nuxt.js) によるフロントエンドと、Ruby on Rails によるバックエンドで構成されています。
Teachme Biz (Web) の大雑把な構成図
上図だけ見ると、Rails が API サーバーに徹しており、非常に簡素で疎結合に見えます。
しかし、Teachme Biz は元々、 SPA ではなかったところを、API の追加やフロントエンドのリプレイスによって SPA 化した経緯があります(以下記事参照)
Rails + Vue.jsでUIリニューアルしてみた(フロントフレームワーク選定編)
そのため、現在でも非SPA時代の名残のような責務を Rails が担い続けている状態になっています。
具体的には、ブラウザからの初回リクエストを Rails がハンドリングするため、API 以外にも以下のような責務を担っています。

リクエストパス、セッションに基づくリダイレクト操作
meta タグの注入(SEO用途など)
CSRF トークンの DOM への注入
リクエストパスに基づいた script が注入 されたHTML のレンダリング
Rails が持つ API 以外の責務は想像以上に大きい
上図の通り、SPA 開始用の HTML を Rails の View(erb)でレンダリングしています。つまり、Rails がなければフロントエンドを開始することすら出来ないということです。
この状態を、本記事では Rails と Vue が密であると定義します。
現状のフロントエンド開発環境の課題
前述のとおり、Teachme Biz は、 Rails と Vue が密な構成になっています。これはユーザー体験の向上やSEOの面では有効に機能しており、これ自体が大きな問題であるとは言えません (とはいえ、もう少し疎にしたい)
では開発環境はどうでしょうか？
アーキテクチャ上は Rails と Vue が密であるとはいえ、アプリケーションの大部分は SPA であり、フロントエンドとバックエンドが REST API でのみ繋いでいるのも事実です。
しかし、この構成である以上、フロントエンドのみの開発をする場合も、Rails を含めたバックエンドの開発環境を構築する必要があります。
バックエンドの開発環境が必須であると、フロントエンドの開発をする上で以下のような課題が生まれます。

Docker / Docker Compose での環境構築の敷居が高い (特にデザイナ)
docker-sync によるホストとゲストの同期が遅く、トラブルも多い
サーバを動かすためのリソースの消費が激しく、応答も遅くなりがち
マイクロサービスに関わる画面をイジる場合は、さらに環境構築が必要
検証に使用するデータを逐一ローカルに用意する必要がある

これらの課題を解消すれば、フロントエンドの開発をさらに効率化できる可能性があることに気づきました。
現状のフロントエンド開発環境の構成
フロントエンドの開発用サーバとして、 webpack-dev-server が動いています。
ブラウザと Rails それぞれ支援する webpack-dev-server
webpack-dev-server は、 webpack のビルド結果をオンメモリで持ちつつ、 WebSocketsを通じて、差分ビルド結果をブラウザに動的に読み込ませる役割を持ちます。
Teachme Biz のアーキテクチャ上、Rails が最新の JavaScript パスを知る必要があるため、Rails も webpack-dev-server にリクエストする、やや特殊な構成となっています。
この構成をベースに、理想のフロントエンド開発環境(以下、新フロント開発環境)を要件を決め、実現していきます。
新フロント開発環境
前述の課題感を解決するため、ここでは、以下を理想のフロントエンド開発環境とします。

Docker を使わずとも、ホストマシン(≒Mac) だけで立ち上がる
Rails を含むバックエンドサーバを立ち上げる必要がない
任意のリモート環境の API を利用できる

また、上記を実現する上で、以下は守るべき大前提とします。

開発環境のためだけのアプリケーションコードを書かない
環境差異を作らない (≒ production と staging で振る舞いを分岐しない)
セキュリティを緩めるような変更をしない

以下のようなイメージで、フロントエンド開発環境のみで任意のサーバのAPI を呼び出せるようにします。
新フロント開発環境のイメージ
理想を阻む３種の壁
新フロント開発環境を、現状のアーキテクチャで実現するためには、解決すべき3つの問題がありました。

クロスオリジンでの XHR が許可されていない
CSRF トークンの検証を突破できない
SPA を開始するための HTML ファイルが手に入らない

それぞれについて、どういう問題なのかを含め、解決策をお話します。
壁１: クロスオリジンでの XHR が許可されていない
開発環境上の Rails (Same Origin) でなく、リモートの Rails (Cross Origin) の API を呼び出すためには、CORS 制約を回避する必要があります。
Webエンジニアが大好きとされる CORS エラー
この問題は、レスポンスの Access-Control-Allow-Origin ヘッダーなどで、オリジンを許可することで回避することが可能です。
Rails(Rack) での CORS設定の例
しかし、この対応ではアプリケーションへの脆弱性が生まれないかを慎重に検討する必要があるため、前提条件を満たせるとは言えません。また、検証環境のみ対応することで、本番環境のセキュリティを維持することはできますが、今度は環境差異が生じるため、これも前提条件に反します。
これではクロスオリジンを許可したいけどクロスオリジンを許可したくないという二律背反になります。
ではどうするか、そもそもクロスオリジンリクエストにならなければ良いのでは？ということで、 webpack-dev-server に、API リクエストをプロキシしてもらう構成にしました。
プロキシによって SameOrigin にみせた CrossOrigin を実現
これは webpack-dev-server の proxy オプションで実現可能です。
target を書き換えれば任意の環境にリクエストできる
この方法の利点は、ブラウザから見たら SameOrigin にリクエストしているつもりなので、アプリケーションコードの改修が不要という点です。
これにより、 webpack-dev-server の設定変更のみで、クロスオリジンリクエストができるようになりました。
壁２: CSRFトークン の検証を突破できない
２つ目の壁は、現状では Rails が View(erb) で埋め込む CSRFトークン の取得が出来ないという問題です。
CSRF トークンとは、CSRF 攻撃への対策として、Rails が用意している protect_from_forgery での検証に使用されるトークンのことです。この仕組みが有効な場合、CSRF攻撃の余地があるリクエストには、事前に発行されたトークンを含まなければブロックされるようになります。
Teachme Biz が元々非SPA であった経緯もあり、現状ではこの CSRF トークンが、Rails の View(erb) を通じて DOM に埋め込まれるため、フロントエンドはそれを取得してリクエストに含む必要があります。
現状の CSRFトークンの受け渡しの流れ
当然ながら上記の方法は、Rails が HTML を生成することを前提としているため、API サーバに徹してもらう理想の開発環境では実現できません。
とはいえ、この問題は歴史的経緯に過ぎない部分もあるため、思い切ってアプリケーションコードを改修し、ログイン後に呼ばれる API のレスポンスにトークンを含んでもらう方式を採用します。
理想の開発環境のための改修
ちなみに該当の API を叩くまでに、CSRF トークンを必要とする API リクエストを必要としなかったことは、偶然にして幸いでした。
壁３: SPA を開始するための HTML ファイルが手に入らない
API の提供を除くと、現状の Rails の最大の責務は、SPA を開始するための HTML のレンダリングとその配信でした。
Rails なしでこれを実現するために、Rails に代わって、webpack-dev-server に HTML を生成、配信する責務を持たせます。
Teachme Biz では、webpack を用いて、機能の分類に応じた3種類のエントリーファイルを、ビルド時に生成します。
webpack.config.js
エントリーファイルが3種類あるため、それぞれを読み込む script タグを注入した HTML ファイルが3種類必要になります。
これは webpack プラグインの一種である、html-webpack-plugin を使用し、ビルドごとに最新のハッシュがついた JS ファイルを読み込む HTML ファイルを出力します。
webpack.config.js生成された HTML ファイル例
これで３種類のエントリーファイルに対応する、login.html / groups.html / manuals.html の３種類の HTML ファイルが出揃いました。
次は、ブラウザの初回リクエスト時のパスに応じた、適切なHTMLファイルを返す仕組みを用意します。
これについては、 webpack-dev-server の historyApiFallback オプションを活用します。
これは、webpack-dev-server が保持していないファイルのリクエストが届いた際、どのようにフォールバックするかを決定するオプションです。
本来は 404ページへのリダイレクトなどに使うものと思われますが、これを活用して、SPA 開始前の論理パスから、生成された HTML ファイルの物理パスへの変換を実現します。
webpack.config.js (細かい正規表現は調整中)
これによって、初回リクエスト時のパスに応じた、SPA 開始用の HTML を webpack-dev-server から手に入れられるようになり、API 以外は Rails に頼る必要がなくなりました。
初回リクエスト時の webpack-dev-server との関係
全ての壁を突破して
これで、新フロント開発環境を阻む３つの壁を突破出来ました。
クロスオリジンでの XHR が許可されていない
→ webpack-dev-server でプロキシすることで解決
CSRFトークン の検証を突破できない
→ DOM 経由でなくAPI でトークンを受け取れるようし解決
SPA を開始するための HTML ファイルが手に入らない
→ webpack, webpack-dev-server で HTML を生成し、リクエストの論理パスに応じて返すことで解決
ここまでの工夫を経て、(わかりづらいですが)以下のように、開発環境のフロントエンドから、リモート環境(∋本番環境) の API を利用できるようになりました。
localhost:3035 だけど本番環境のマニュアル一覧が取得できている
新フロント開発環境では引き続き webpack-dev-server が動いているため、ホットリロードなどの従来の仕組みはそのまま、バックエンドの環境は一切用意せずに開発できるようになりました。
まとめと今後の展望
本記事では、Rails と Vue が密結合になっているアプリケーションを、フロントエンド単体で開発できるように分離した、新フロント開発環境を構築しました。
もちろんアプリケーション自体の Rails と Vue の密結合は変わっていないため、境界部分の開発、検証用に従来の開発環境も残す形となりましたが、SPA 部分に限定した開発を行う場合は使い分けることで、開発効率を飛躍的に高めることが出来たと思います。
今後は webpack-dev-server に持たせている責務を Vite に載せかえることでさらなる高速化を図ったり、開発環境に閉じない、プロダクト自体の疎結合化を進め、スケールやデプロイしやすくすることも考えています。
We are hiring.
スタディスト開発部では、こういった開発基盤の改善にも力を入れられる土壌が整っています。本記事を読み、少しでもスタディスト開発部が気になった方は、まずはお気軽にご連絡いただけると嬉しいです。
株式会社スタディストの会社情報 - Wantedly

Rails と密なフロントエンドの開発環境を分離するための3つの工夫 was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rails と密なフロントエンドの開発環境を分離するための3つの工夫

スタディスト 開発部 技術支援ユニットの笹木 (<a href="http://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。本記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。なお、本記事の内容は、移行開始直後の登壇資料 “<a href="https://www.slideshare.net/shingosasaki3/vue-typescript">大規模 Vue アプリケーションの TypeScript 移行</a>” と、移行完了後の登壇資料 “<a href="https://www.slideshare.net/shingosasaki3/6-typescript">6万行の TypeScript 移行とその後</a>” と重複する内容を含んでいます。<h3>Teachme Biz と TypeScript</h3>弊社が開発している、マニュアル作成・共有システム <a href="https://biz.teachme.jp/">Teachme Biz</a> は、iOS/Android や Windows など、マルチプラットフォームで提供されています。その中でも、作成・管理に多く使われている Webブラウザ版は、 JavaScript と Vue.js を主とした、以下のような技術構成となっており、歴史的経緯もあって TypeScript は使用していませんでした。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BHzrwXsss2q1OW2ZXlNy3Q.png" /><figcaption>移行開始以前の技術構成</figcaption></figure>Web開発における TypeScript の重要性は語るまでもありません。弊社でも、型がないことによる以下の四大リスクを抱え、不具合が発生しやすい上、開発効率が低い状態が続いていました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ThtY8HdoDUIsv8CAXqseqw.png" /><figcaption>四大リスク</figcaption></figure><ul><li>危険: Null を含むどんな値が入っているか推測しづらい</li><li>無秩序: コードの自由度が高まり、一貫性のないコードが量産される</li><li>非効率: エディタの推論が満足に効かず、タイポが起こりやすい</li><li>暗黙知: 設計に関する情報がコードから得づらい</li></ul>上記の四大リスクは、型の力で以下のように解決することができます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6SOA0jTFDSo2CvZsukS8fA.png" /><figcaption>かた の ちから ってすげー</figcaption></figure>これまでは四大リスクをだましだまし受け入れ続けてきましたが、長期的なスケールや、Vue 3 へのマイグレーションなどを見越すと、移行は今しかないという判断に至りました。<h3>移行範囲</h3>移行を決意したとはいえ、どこまでをどのレベルで移行するのかを予め決める必要があります。結論から言うと、以下のような方針で移行を行うことにしました。<ul><li>.js ファイルは(一部の例外を除いて) 全て移行する</li><li>.vue ファイルは一切移行しない</li><li>strict: true のルールを設定する</li><li>plugin:@typescript-eslint/recommended を使用する</li></ul>Vue を対象外としたのは、Vue 3 へのマイグレーションを考慮した時、どのみちコンポーネントの書き直しが発生したり、型の使い方が変わったりと二度手間になりえるからです。.js ファイルについては、基本的に全てのファイルを対象とし、 tsconfig や eslint での厳しい設定を付与します。これによって、implicit any や ts-ignore を使用した、”移行はしてるが全然型安全じゃない”という半端な状態を減らします。 (明示的な any 自体は禁止せず、今後の課題とする)<h3>開発チームとの認識合わせ</h3>既存コードの TypeScript 移行を進めても、各開発チームが新規コードを従来どおり JavaScript で書いてしまうと、アキレスと亀のような状態になり、移行がいつまでも完了しません。そこで、まずは開発チーム全体に、本記事で書かれているような背景とプロセスを共有し、新規コードは基本的に TypeScript で書いてもらいつつ、既存コードを改修する場合も、可能な限り TypeScript を使うように認識を揃えました。もちろん多くのメンバーは TypeScript 未経験であるため、相互レビューを強化したり、<a href="https://book.mynavi.jp/ec/products/detail/id=104703">実践 TypeScript</a> の輪読を行うなど、社内への TypeScript の布教を心がけました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/391/1*ag-uicHNPyNwpGvoNkBmDw.jpeg" /><figcaption>輪読に使用した書籍</figcaption></figure><h3>移行プロセス</h3>移行対象が .js ファイルのみとはいえ、コードベース上のJSファイルは、テストコードも含めると累計で6万行存在するため、計画的に移行を進める必要があります。充分な時間があるとはいえ、他の開発チームの業務は止めず、なるべく邪魔にならないようにするためには、移行するファイルと機能開発で修正されるファイルの衝突を、最小限に留める必要があります。そのため、移行用の作業ブランチを切るということはせず、ファイルまたはフォルダ単位で小さく移行し、個別に PR を作成、素早くマージ(≒リリース) するというサイクルを繰り返しました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*K-IhOGjFe-tHjxDC_i8M2g.png" /><figcaption>全て master ブランチ向きの PR</figcaption></figure>なお、細かい移行順序や工夫点は、<a href="https://uit-inside.linecorp.com/">UIT INSIDE</a> で話されていた LINE 様の事例を参考にしています。 (いつも楽しく聴いてます!)<ul><li><a href="https://uit-inside.linecorp.com/episode/55">ep.55 TypeScriptへのマイグレーション対応開始！LINEポイントクラブのリファクタについて聞いてみた。 | UIT INSIDE</a></li><li><a href="https://uit-inside.linecorp.com/episode/77">ep.77 TypeScriptマイグレーション進捗報告！LINE ポイントクラブがかけたリソースと回収状況 | UIT INSIDE</a></li></ul><h3>検証プロセス</h3>前述のように、小さく移行してリリースのサイクルを回すということは、それだけ本番環境のコードが頻繁に書き換わるということです。開発のリスク軽減のための TypeScript 移行のせいで、新たに障害が起こるようでは本末転倒。ここでバグを出すわけにはいきません。幸いにも Teachme Biz の開発環境は、 CI/CD プロセスが充分に整備されています。コードをプッシュするたびに、以下のテストが CircleCI 上で実行されるので、基本的には CI が通れば OK と判断できます。<ul><li>単体テスト(Jest)</li><li>E2Eテスト(Selenium)</li><li>Visual Regression Testing (Storybook + reg-suit)</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*eJc61G6oQFWRD173BGKnkA.png" /><figcaption>内製のE2Eテストレポート画面</figcaption></figure>自動テストをパスしても不安の残る改修がある場合、検証環境を立上げて、個別に手動検証を行います。検証環境については、実行基盤が kubernetes に移行したこともあり、簡単なコマンドで、インスタントな独立した環境を立ち上げることができます。kubernetes については以下記事を御覧ください。<a href="https://medium.com/studist-dev/studist-sre-and-kubernetes-49d1de1c4be6">Teachme Bizの基盤をEC2からEKSへ移行した話</a>ここまでしてなお不安が残る場合、別途 QA グループに相談します。開発者自身では見つけられない、思いつきもしない不具合を、的確な検証で探り出してもらえます。<h3>リファクタリング</h3>TypeScript 移行に関しては、多くのブログや書籍で事例が紹介されていますが、リファクタリングを同時に行うべきか否かという問題がよく上がります。多くの場合、リファクタリングは別枠考えるべきとも言われています。以下の事例を具体的に見てみましょう。<a href="https://logmi.jp/tech/articles/324487">移行のメリットはコストを上回るか？　JavaScriptのTypeScript化で気をつけるべき5つのポイント</a><blockquote>4つ目は逆説的なんですが、「リファクタリングとTypeScript移行を同時に行わない」ということです。TypeScript移行に関しては、対象となるファイルがアプリ全体で非常に広いので、リファクタリングとTypeScript移行を同時にやってしまうと、リグレッションテストが落ちたときに、その原因が移行時に意図せず混入したバグなのか、それともリファクタリングの影響なのか切り分けが非常に難しくなります。</blockquote><blockquote>またこちらのほうが大事なのですが、リファクタリングは始めるときりがなくなります。今回変更はアプリ全体に影響する可能性があるので、リファクタリングをし始めるとあれもこれも気になって、いつまでたってもTypeScript移行が終わらないという状況に陥ります。</blockquote>全面的に同意です。多くの場合はその選択が正しいと思います。しかし弊社では、逆にリファクタリングをイケるところまでやりながら TypeScript 移行しようという方針にしました。主な理由は以下のとおりです。<ul><li>前述の検証プロセスが非常に充実しているので、デグレリスクが低い</li><li>自身が専任で TypeScript 移行を行っているため、時間が充分にある</li><li>未来は予想できないため、「あとでリファクタする」で本当にリファクタするとは限らない</li><li>リファクタせずに現行コードに型を付けると、カオスな型が出来上がる</li></ul>個人的には最後のが大きいです。型のない世界で、勢いで書かれたコードは、データ構造を無視しがちで、その全てに対応する型を定義しようとすると、引きずられておかしな型が出来上がります。また、このタイミングで旧機能の不要コードや、参照されないデッドコードを洗い出すことで、余計な型定義を減らすこともできます。そのため、あるべき型を定義し、そぐわないコードを修正するリファクタ作業を同時に行うことで、コード品質自体を高めるというのを目指しました。<h3>進捗管理</h3>全ての JS ファイルを移行対象にするといいつつ、様々な経緯で移行不可能なファイルも少なくありません。そこで、半期の間に 70% の移行を完了させるという OKR を掲げ、それを TypeScript 移行完了のゴールと定義しました。進捗率のトラッキングは、masterブランチの各コミット時点での TS ファイルと JS ファイルの総数(及び行数) の比率を計測するようにしました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9ccAaqli-an1Paw9G9d9KA.png" /><figcaption>計測用コードのイメージ</figcaption></figure>上記スクリプトを用いて集計し、ペース配分を見ながら、半年間移行作業を続けることで、8月末にちょうど目標に到達することができました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tF05L0gOCPlwl7H5c7RNnQ.png" /><figcaption>7月後半に急激に増加してるのは Storybook コードの一括置換によるもの</figcaption></figure><h3>まとめ</h3>本記事では、JavaScript のコード6万行を、機能開発を止めずに、1人で TypeScript に移行することができた要因を整理しました。弊社では以下のような条件が揃っていたことから、TypeScript 移行をリファクタリング込みで実現できたと言えます。<ul><li>技術支援ユニットという、機能開発から独立した部隊が存在する</li><li>各社の事例を事前に分析し、進め方を決めてから着手した</li><li>期間と範囲を決め、トラッキングしながら集中対応した</li><li>CI/CD によって、自動テスト/手動テストのための仕組みが揃っていた</li></ul><h3>最後に</h3>スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=90b99b7c8974" width="1" height="1" alt=""><hr><a href="https://studist.tech/typescript-migration-90b99b7c8974">機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。
本記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。
なお、本記事の内容は、移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” と、移行完了後の登壇資料 “6万行の TypeScript 移行とその後” と重複する内容を含んでいます。
Teachme Biz と TypeScript
弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/Android や Windows など、マルチプラットフォームで提供されています。
その中でも、作成・管理に多く使われている Webブラウザ版は、 JavaScript と Vue.js を主とした、以下のような技術構成となっており、歴史的経緯もあって TypeScript は使用していませんでした。
移行開始以前の技術構成
Web開発における TypeScript の重要性は語るまでもありません。弊社でも、型がないことによる以下の四大リスクを抱え、不具合が発生しやすい上、開発効率が低い状態が続いていました。
四大リスク
危険: Null を含むどんな値が入っているか推測しづらい
無秩序: コードの自由度が高まり、一貫性のないコードが量産される
非効率: エディタの推論が満足に効かず、タイポが起こりやすい
暗黙知: 設計に関する情報がコードから得づらい

上記の四大リスクは、型の力で以下のように解決することができます。
かた の ちから ってすげー
これまでは四大リスクをだましだまし受け入れ続けてきましたが、長期的なスケールや、Vue 3 へのマイグレーションなどを見越すと、移行は今しかないという判断に至りました。
移行範囲
移行を決意したとはいえ、どこまでをどのレベルで移行するのかを予め決める必要があります。
結論から言うと、以下のような方針で移行を行うことにしました。

.js ファイルは(一部の例外を除いて) 全て移行する
.vue ファイルは一切移行しない
strict: true のルールを設定する
plugin:@typescript-eslint/recommended を使用する

Vue を対象外としたのは、Vue 3 へのマイグレーションを考慮した時、どのみちコンポーネントの書き直しが発生したり、型の使い方が変わったりと二度手間になりえるからです。
.js ファイルについては、基本的に全てのファイルを対象とし、 tsconfig や eslint での厳しい設定を付与します。これによって、implicit any や ts-ignore を使用した、”移行はしてるが全然型安全じゃない”という半端な状態を減らします。 (明示的な any 自体は禁止せず、今後の課題とする)
開発チームとの認識合わせ
既存コードの TypeScript 移行を進めても、各開発チームが新規コードを従来どおり JavaScript で書いてしまうと、アキレスと亀のような状態になり、移行がいつまでも完了しません。
そこで、まずは開発チーム全体に、本記事で書かれているような背景とプロセスを共有し、新規コードは基本的に TypeScript で書いてもらいつつ、既存コードを改修する場合も、可能な限り TypeScript を使うように認識を揃えました。
もちろん多くのメンバーは TypeScript 未経験であるため、相互レビューを強化したり、実践 TypeScript の輪読を行うなど、社内への TypeScript の布教を心がけました。
輪読に使用した書籍
移行プロセス
移行対象が .js ファイルのみとはいえ、コードベース上のJSファイルは、テストコードも含めると累計で6万行存在するため、計画的に移行を進める必要があります。
充分な時間があるとはいえ、他の開発チームの業務は止めず、なるべく邪魔にならないようにするためには、移行するファイルと機能開発で修正されるファイルの衝突を、最小限に留める必要があります。
そのため、移行用の作業ブランチを切るということはせず、ファイルまたはフォルダ単位で小さく移行し、個別に PR を作成、素早くマージ(≒リリース) するというサイクルを繰り返しました。
全て master ブランチ向きの PR
なお、細かい移行順序や工夫点は、UIT INSIDE で話されていた LINE 様の事例を参考にしています。 (いつも楽しく聴いてます!)

ep.55 TypeScriptへのマイグレーション対応開始！LINEポイントクラブのリファクタについて聞いてみた。 | UIT INSIDE
ep.77 TypeScriptマイグレーション進捗報告！LINE ポイントクラブがかけたリソースと回収状況 | UIT INSIDE

検証プロセス
前述のように、小さく移行してリリースのサイクルを回すということは、それだけ本番環境のコードが頻繁に書き換わるということです。
開発のリスク軽減のための TypeScript 移行のせいで、新たに障害が起こるようでは本末転倒。ここでバグを出すわけにはいきません。
幸いにも Teachme Biz の開発環境は、 CI/CD プロセスが充分に整備されています。
コードをプッシュするたびに、以下のテストが CircleCI 上で実行されるので、基本的には CI が通れば OK と判断できます。

単体テスト(Jest)
E2Eテスト(Selenium)
Visual Regression Testing (Storybook + reg-suit)
内製のE2Eテストレポート画面
自動テストをパスしても不安の残る改修がある場合、検証環境を立上げて、個別に手動検証を行います。
検証環境については、実行基盤が kubernetes に移行したこともあり、簡単なコマンドで、インスタントな独立した環境を立ち上げることができます。kubernetes については以下記事を御覧ください。
Teachme Bizの基盤をEC2からEKSへ移行した話
ここまでしてなお不安が残る場合、別途 QA グループに相談します。開発者自身では見つけられない、思いつきもしない不具合を、的確な検証で探り出してもらえます。
リファクタリング
TypeScript 移行に関しては、多くのブログや書籍で事例が紹介されていますが、リファクタリングを同時に行うべきか否かという問題がよく上がります。多くの場合、リファクタリングは別枠考えるべきとも言われています。
以下の事例を具体的に見てみましょう。
移行のメリットはコストを上回るか？　JavaScriptのTypeScript化で気をつけるべき5つのポイント
4つ目は逆説的なんですが、「リファクタリングとTypeScript移行を同時に行わない」ということです。TypeScript移行に関しては、対象となるファイルがアプリ全体で非常に広いので、リファクタリングとTypeScript移行を同時にやってしまうと、リグレッションテストが落ちたときに、その原因が移行時に意図せず混入したバグなのか、それともリファクタリングの影響なのか切り分けが非常に難しくなります。
またこちらのほうが大事なのですが、リファクタリングは始めるときりがなくなります。今回変更はアプリ全体に影響する可能性があるので、リファクタリングをし始めるとあれもこれも気になって、いつまでたってもTypeScript移行が終わらないという状況に陥ります。
全面的に同意です。多くの場合はその選択が正しいと思います。
しかし弊社では、逆にリファクタリングをイケるところまでやりながら TypeScript 移行しようという方針にしました。主な理由は以下のとおりです。

前述の検証プロセスが非常に充実しているので、デグレリスクが低い
自身が専任で TypeScript 移行を行っているため、時間が充分にある
未来は予想できないため、「あとでリファクタする」で本当にリファクタするとは限らない
リファクタせずに現行コードに型を付けると、カオスな型が出来上がる

個人的には最後のが大きいです。型のない世界で、勢いで書かれたコードは、データ構造を無視しがちで、その全てに対応する型を定義しようとすると、引きずられておかしな型が出来上がります。また、このタイミングで旧機能の不要コードや、参照されないデッドコードを洗い出すことで、余計な型定義を減らすこともできます。
そのため、あるべき型を定義し、そぐわないコードを修正するリファクタ作業を同時に行うことで、コード品質自体を高めるというのを目指しました。
進捗管理
全ての JS ファイルを移行対象にするといいつつ、様々な経緯で移行不可能なファイルも少なくありません。そこで、半期の間に 70% の移行を完了させるという OKR を掲げ、それを TypeScript 移行完了のゴールと定義しました。
進捗率のトラッキングは、masterブランチの各コミット時点での TS ファイルと JS ファイルの総数(及び行数) の比率を計測するようにしました。
計測用コードのイメージ
上記スクリプトを用いて集計し、ペース配分を見ながら、半年間移行作業を続けることで、8月末にちょうど目標に到達することができました。
7月後半に急激に増加してるのは Storybook コードの一括置換によるもの
まとめ
本記事では、JavaScript のコード6万行を、機能開発を止めずに、1人で TypeScript に移行することができた要因を整理しました。
弊社では以下のような条件が揃っていたことから、TypeScript 移行をリファクタリング込みで実現できたと言えます。

技術支援ユニットという、機能開発から独立した部隊が存在する
各社の事例を事前に分析し、進め方を決めてから着手した
期間と範囲を決め、トラッキングしながら集中対応した
CI/CD によって、自動テスト/手動テストのための仕組みが揃っていた

最後に
スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！
株式会社スタディストの会社情報 - Wantedly

機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス

<h3>webpack 5 にアップグレードしました</h3>スタディスト 開発部 技術支援ユニットの笹木 (<a href="https://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。今回は、弊社が開発・運用している <a href="https://biz.teachme.jp/">TeachmeBiz</a> でも使用している、<a href="https://webpack.js.org/">webpack</a> を 4系から5系にアップグレードし、開発体験を向上させたお話です。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gdoQ1_5OID90wf1eLTFvWw.png" /><figcaption><a href="https://webpack.js.org/branding/">webpack</a></figcaption></figure>webpack 4 -&gt; 5 のアップグレードについては、<a href="https://www.google.com/search?q=webpack+4+5&amp;oq=webpack+4+5&amp;aqs=chrome.0.0l6j69i60l2.1484j0j7&amp;sourceid=chrome&amp;ie=UTF-8">既に多くの事例</a>がありますが、移行の手順や発生する問題というのは、プロダクトの特性や現在の構成に大きく依存するところもあるため、スタディストではどうだったかを改めて紹介致します。<h4>TL;DR</h4><ul><li>webpack 4.x から webpack 5.x へのアップグレードはすんなりできた</li><li>ビルドコストを 1/3 削減することができた</li><li>Dependabot から通知される脆弱性のほとんどに対応もできた</li></ul><h4>TeachmeBiz の技術構成</h4>TeachmeBiz のフロントエンドは、主に以下の技術構成となっています。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cHecQFybaa5w4Ld_dpIUUg.png" /></figure>基本的には <a href="https://jp.vuejs.org/index.html">Vue</a> を用いた SPA で、 <a href="https://ja.nuxtjs.org/">Nuxt.js</a> などのフレームワークは使用していないため、 <a href="https://babeljs.io/">Babel</a> / <a href="https://www.typescriptlang.org/">TypeScript</a> を含めた webpack 周りを自分たちで管理しています。そのため、以下の webpack 関連パッケージに依存しています。(内、太字が特にアップグレードの影響を受けるパッケージ)<ul><li>webpack 4.42.1</li><li>webpack-cli 3.3.11</li><li>webpack-dev-server 3.10.3</li><li>webpack-manifest-plugin 2.0.3</li><li>webpack-merge 4.1.3</li><li>hard-source-webpack-plugin 0.13.1</li><li>terser-webpack-plugin 3.0.2</li><li>moment-locales-webpack-plugin 1.1.0</li><li>babel-loader 8.0.6</li><li>css-loader 1.0.1</li><li>file-loader 1.1.11</li><li>sass-loader 7.0.3</li><li>style-loader 0.21.0</li><li>vue-loader 15.6.2</li><li>vue-style-loader 0.21.0</li><li>@storybook/vue 6.2.9</li></ul>webpack 5 がリリースされたのは<a href="https://github.com/webpack/webpack/releases/tag/v5.0.0">2020年10月</a>でしたが、TeachmeBiz では上記の通り、多くの 関連パッケージに依存しているため、それら全てが webpack 5 をサポートするのを待つ必要がありました。2021年06月、webpack 5 のサポートを含んだ <a href="https://storybook.js.org/blog/storybook-6-3/">Storybook 6.3 </a>がリリースされ、ようやく全てのツールが対応されたことから、満を持してアップグレード作業をはじめました。<h4>アップグレード手順</h4>今回実施したアップグレード作業は、概ね以下の流れになっています。<ol><li>マイグレーションガイドを一読する</li><li>関連パッケージを最新化</li><li>ビルドする</li><li>エラーが出る</li><li>エラーを対処する</li><li>ビルドに成功するまで 4,5の繰り返し</li><li>CI が通るまで 4,5 の繰り返し</li></ol>本記事では割愛しますが、弊社には強力な自動テストプロセス(単体テスト、コンポーネントテスト、E2Eテスト、Visual Regression Test) が整備されているため、人力による検証は最後の最後に QA にお願いするだけで、基本的には CI での検証のみとなっています。<h4>マイグレーションガイドを一読</h4>パッケージを更新するとか、設定ファイルを調整するといった作業に入る前に、公式から案内されている<a href="https://webpack.js.org/migrate/5/">マイグレーションガイド</a>に目を通します。いくつか、後述する個々のトラブルシューティングに必須の内容も含まれていますが、全体を通して以下を意識して進めることにしました。<ul><li>パッケージは全て最新版を利用する</li><li>— trace-deprecation オプションなど、警告を出力する設定を常に使う</li></ul><h4>パッケージの一括アップグレード</h4>続けて関連パッケージのバージョンを上げます。メジャーバージョンが上がったパッケージだけ抜き出しても、このぐらい上がりました。<ul><li>webpack 4.x → 5.38.1</li><li>webpack-cli 3.x → 4.7.0</li><li>webpack-manifest-plugin 2.x → 3.x</li><li>webpack-merge 4.x → 5.x</li><li>file-loader 1.x → 6.x</li><li>css-loader 1.x → 5.x</li><li>sass-loader 7.x → 12.x</li><li>style-loader 0.21.x → 2.x</li></ul>また、<a href="https://dependabot.com/">Dependabot</a> から通知される脆弱性通知のほとんどを、これによって解消することができました。多くは開発環境に限定され、緊急度の低い脆弱性ではありましたが、こういったタイミングで潰しておくことで、本当に重要な脆弱性を見逃さずに済むと思います。<h4>サポートブラウザを明示する</h4>webpack 5 では、デフォルトで ES2015 を含んだランタイムコードを生成するようになりました。そのため、IE11 のようなレガシーブラウザをサポートするプロダクトの場合、明示的にサポートブラウザを指定する必要があります。設定方法はいくつかありますが、package.json 内に <a href="https://github.com/browserslist/browserslist">browserslist</a> の定義があれば、それを参照してくれるため、<a href="https://babeljs.io/docs/en/babel-preset-env">@babel/preset-env</a> など他のツールでも参照できるように、ここで一元管理します。<pre>&quot;browserslist&quot;: [ &quot;IE 11&quot;, &quot;last 1 chrome versions&quot;, &quot;last 1 ChromeAndroid versions&quot;, &quot;last 1 firefox versions&quot;, &quot;last 1 safari versions&quot;, &quot;iOS &gt;= 11.4&quot; ]</pre><h4>ビルドキャッシュを有効化する</h4>webpack 5 からは、ビルド結果をキャッシュして再ビルド時に差分ビルドだけで済ませることでパフォーマンスを改善する、<a href="https://webpack.js.org/guides/caching/">キャッシュ機能</a>が本体に組み込まれています。キャッシュ機能はビルド効率が高まる反面、キャッシュの作り方次第ではビルドに失敗するリスクも含んでいます。Teachme Biz では元々 <a href="https://zenn.dev/sa2knight/articles/7e4d6b43780d9fc47ab1">webpack-hardsource-plugin</a> を用いてキャッシュを使用していたため、リスクよりも効率を優先し、引き続きキャッシュを使っていきます。(development/test環境のみ)<pre>cache: { type: &#39;filesystem&#39;, buildDependencies: { config: [__filename] } }</pre><h4>file-loader / url-loader を廃止し、Asset Modules を使用する</h4>webpack 4 以前では、画像ファイルへの依存を解決するために、 <a href="https://v4.webpack.js.org/loaders/file-loader/">file-loader</a> などのローダーを別途設定する必要がありましたが、webpack 5 からは <a href="https://webpack.js.org/guides/asset-modules/">Asset Modules</a> の仕組みを使うことで、ローダーなしで依存解決できるようになりました。<pre>module: { rules: { test: /\.(png|jpe?g|gif|svg|cur|mp4)(\?.*)?$/, type: &#39;asset/resource&#39; } }</pre><h4>プラグインのインポート方法を変更</h4>webpack-manifest-plugin / webpack-merge は、メジャーバージョンが上がり、エクスポートされるオブジェクトの構造が変化したため、インポート側も修正します。<pre>// 旧 const merge = require(&#39;webpack-merge&#39;) const ManifestPlugin = require(&#39;webpack-manifest-plugin&#39;)</pre><pre>// 新 const { merge } = require(&#39;webpack-merge&#39;) const { WebpackManifestPlugin } = require(&#39;webpack-manifest-plugin&#39;)</pre><h4>webpack-dev-server の実行コマンドを変更</h4>開発用サーバである webpack-dev-server の実行コマンドが変更され、webpack-cli を用いるようになったため、あわせて変更します。<pre>$ yarn webpack-dev-server // 旧 $ yarn webpack-cli serve // 新</pre><h4>Storybook を動くようにする</h4>Storybook 6.3 から、満を持して webpack 5 が正式にサポートされました。本バージョンでは、Storybook 全体をビルドするための Manager Builder と、個々のストーリー(≒コンポーネント) を描画するための Preview Builder が分離され、Preview Builder として webpack 5 が使えるようになりました。(詳細は<a href="https://storybook.js.org/blog/storybook-for-webpack-5/">公式ブログ</a>参照)Preview Builder の変更は、専用パッケージを導入します。<pre>$ yarn add -D @storybook/builder-webpack5 $ yarn add -D @storybook/manager-webpack5</pre>builder に webpack5 を使用することを .storybook/main.js に記述します。<pre>module.exports = { core: { builder: &#39;webpack5&#39; } }</pre><h4>パフォーマンスを計測する</h4>以上の工程を得て、概ね対応は完了したので、 webpack 4 から 5 へのアップグレードによるビルドコストがどう変化したのかを評価します。Web 開発における webpack の役割は幅広く、何をもって改善したかを計測するのは難しいですが、今回は以下コマンドによるテスト用ビルドの実行時間を指標とします。<pre>$ yarn webpack --progress --color --config webpack/test.js</pre>webpack/test.js はテスト用の設定に一部書き換えたものですが、基本的な依存解決ルール、成果物のアウトプットルールは本番と同様になってます。実行環境やキャッシュの有無での差異が生じないように、 <a href="https://circleci.com/ja/">CircleCI</a> を用いたコンテナ環境上で、 webpack 4 / webpack 5 のそれぞれのブランチでのジョブを確認します。ランダムにサンプリングし、ビルド時間の平均値をとったところ、以下のような結果になりました。<blockquote>webpack 4.x: 54秒</blockquote><blockquote>webpack 5.x: 36秒</blockquote>正直どのあたりの改修が効いたのかはわかりませんが、実に1/3 ものビルドコストが削減できました。<h4>まとめ</h4>本記事のように、大きな基盤改善は行わずに、 webpack のバージョンを上げるだけでも、ビルドコストを大きく削減することができました。とはいえ、それでも 36 秒もの時間がかかっている事実から、既に TeachmeBiz は webpack で開発をするには大きくなりすぎた印象も受けます。そこで、次回は <a href="https://github.com/vitejs/vite">Vite</a> を始めとした、話題の <a href="https://github.com/evanw/esbuild">esbuild</a> を用いた爆速開発環境を構築し、開発環境と本番環境でそもそも基盤を分けるというアプローチにもトライしてみようと考えています。<h4>最後に</h4>スタディストでは、こういった技術基盤の改善にも力を入れています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているため、是非ご興味がありましたら下記リンクより、よろしくおねがいします。<ul><li><a href="https://www.wantedly.com/projects/676472">BtoB SaaS を扱うマイクロサービス開発チームのWebエンジニア募集 by 株式会社スタディスト</a></li><li><a href="https://www.wantedly.com/projects/676450">BtoB SaaS を扱う動画編集機能開発チームのWebエンジニア募集 by 株式会社スタディスト</a></li></ul><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3df31da8e7a2" width="1" height="1" alt=""><hr><a href="https://studist.tech/migration-webpack-from-4-to-5-3df31da8e7a2">webpack 5 に移行しました</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

webpack 5 にアップグレードしました
スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
今回は、弊社が開発・運用している TeachmeBiz でも使用している、webpack を 4系から5系にアップグレードし、開発体験を向上させたお話です。
webpack
webpack 4 -> 5 のアップグレードについては、既に多くの事例がありますが、移行の手順や発生する問題というのは、プロダクトの特性や現在の構成に大きく依存するところもあるため、スタディストではどうだったかを改めて紹介致します。
TL;DR

webpack 4.x から webpack 5.x へのアップグレードはすんなりできた
ビルドコストを 1/3 削減することができた
Dependabot から通知される脆弱性のほとんどに対応もできた

TeachmeBiz の技術構成
TeachmeBiz のフロントエンドは、主に以下の技術構成となっています。

基本的には Vue を用いた SPA で、 Nuxt.js などのフレームワークは使用していないため、 Babel / TypeScript を含めた webpack 周りを自分たちで管理しています。
そのため、以下の webpack 関連パッケージに依存しています。(内、太字が特にアップグレードの影響を受けるパッケージ)

webpack 4.42.1
webpack-cli 3.3.11
webpack-dev-server 3.10.3
webpack-manifest-plugin 2.0.3
webpack-merge 4.1.3
hard-source-webpack-plugin 0.13.1
terser-webpack-plugin 3.0.2
moment-locales-webpack-plugin 1.1.0
babel-loader 8.0.6
css-loader 1.0.1
file-loader 1.1.11
sass-loader 7.0.3
style-loader 0.21.0
vue-loader 15.6.2
vue-style-loader 0.21.0
@storybook/vue 6.2.9

webpack 5 がリリースされたのは2020年10月でしたが、TeachmeBiz では上記の通り、多くの 関連パッケージに依存しているため、それら全てが webpack 5 をサポートするのを待つ必要がありました。
2021年06月、webpack 5 のサポートを含んだ Storybook 6.3 がリリースされ、ようやく全てのツールが対応されたことから、満を持してアップグレード作業をはじめました。
アップグレード手順
今回実施したアップグレード作業は、概ね以下の流れになっています。

マイグレーションガイドを一読する
関連パッケージを最新化
ビルドする
エラーが出る
エラーを対処する
ビルドに成功するまで 4,5の繰り返し
CI が通るまで 4,5 の繰り返し

本記事では割愛しますが、弊社には強力な自動テストプロセス(単体テスト、コンポーネントテスト、E2Eテスト、Visual Regression Test) が整備されているため、人力による検証は最後の最後に QA にお願いするだけで、基本的には CI での検証のみとなっています。
マイグレーションガイドを一読
パッケージを更新するとか、設定ファイルを調整するといった作業に入る前に、公式から案内されているマイグレーションガイドに目を通します。
いくつか、後述する個々のトラブルシューティングに必須の内容も含まれていますが、全体を通して以下を意識して進めることにしました。

パッケージは全て最新版を利用する
— trace-deprecation オプションなど、警告を出力する設定を常に使う

パッケージの一括アップグレード
続けて関連パッケージのバージョンを上げます。メジャーバージョンが上がったパッケージだけ抜き出しても、このぐらい上がりました。

webpack 4.x → 5.38.1
webpack-cli 3.x → 4.7.0
webpack-manifest-plugin 2.x → 3.x
webpack-merge 4.x → 5.x
file-loader 1.x → 6.x
css-loader 1.x → 5.x
sass-loader 7.x → 12.x
style-loader 0.21.x → 2.x

また、Dependabot から通知される脆弱性通知のほとんどを、これによって解消することができました。多くは開発環境に限定され、緊急度の低い脆弱性ではありましたが、こういったタイミングで潰しておくことで、本当に重要な脆弱性を見逃さずに済むと思います。
サポートブラウザを明示する
webpack 5 では、デフォルトで ES2015 を含んだランタイムコードを生成するようになりました。そのため、IE11 のようなレガシーブラウザをサポートするプロダクトの場合、明示的にサポートブラウザを指定する必要があります。
設定方法はいくつかありますが、package.json 内に browserslist の定義があれば、それを参照してくれるため、@babel/preset-env など他のツールでも参照できるように、ここで一元管理します。
"browserslist": [
  "IE 11",
  "last 1 chrome versions",
  "last 1 ChromeAndroid versions",
  "last 1 firefox versions",
  "last 1 safari versions",
  "iOS >= 11.4"
]
ビルドキャッシュを有効化する
webpack 5 からは、ビルド結果をキャッシュして再ビルド時に差分ビルドだけで済ませることでパフォーマンスを改善する、キャッシュ機能が本体に組み込まれています。
キャッシュ機能はビルド効率が高まる反面、キャッシュの作り方次第ではビルドに失敗するリスクも含んでいます。Teachme Biz では元々 webpack-hardsource-plugin を用いてキャッシュを使用していたため、リスクよりも効率を優先し、引き続きキャッシュを使っていきます。(development/test環境のみ)
cache: {
  type: 'filesystem',
  buildDependencies: {
    config: [__filename]
  }
}
file-loader / url-loader を廃止し、Asset Modules を使用する
webpack 4 以前では、画像ファイルへの依存を解決するために、 file-loader などのローダーを別途設定する必要がありましたが、webpack 5 からは Asset Modules の仕組みを使うことで、ローダーなしで依存解決できるようになりました。
module: {
  rules: {
    test: /\.(png|jpe?g|gif|svg|cur|mp4)(\?.*)?$/,
    type: 'asset/resource'
  }
}
プラグインのインポート方法を変更
webpack-manifest-plugin / webpack-merge は、メジャーバージョンが上がり、エクスポートされるオブジェクトの構造が変化したため、インポート側も修正します。
// 旧
const merge = require('webpack-merge')
const ManifestPlugin = require('webpack-manifest-plugin')
// 新
const { merge } = require('webpack-merge')
const { WebpackManifestPlugin } = require('webpack-manifest-plugin')
webpack-dev-server の実行コマンドを変更
開発用サーバである webpack-dev-server の実行コマンドが変更され、webpack-cli を用いるようになったため、あわせて変更します。
$ yarn webpack-dev-server // 旧
$ yarn webpack-cli serve  // 新
Storybook を動くようにする
Storybook 6.3 から、満を持して webpack 5 が正式にサポートされました。
本バージョンでは、Storybook 全体をビルドするための Manager Builder と、個々のストーリー(≒コンポーネント) を描画するための Preview Builder が分離され、Preview Builder として webpack 5 が使えるようになりました。(詳細は公式ブログ参照)
Preview Builder の変更は、専用パッケージを導入します。
$ yarn add -D @storybook/builder-webpack5
$ yarn add -D @storybook/manager-webpack5
builder に webpack5 を使用することを .storybook/main.js に記述します。
module.exports = {
  core: {
    builder: 'webpack5'
  }
}
パフォーマンスを計測する
以上の工程を得て、概ね対応は完了したので、 webpack 4 から 5 へのアップグレードによるビルドコストがどう変化したのかを評価します。
Web 開発における webpack の役割は幅広く、何をもって改善したかを計測するのは難しいですが、今回は以下コマンドによるテスト用ビルドの実行時間を指標とします。
$ yarn webpack --progress --color --config webpack/test.js
webpack/test.js はテスト用の設定に一部書き換えたものですが、基本的な依存解決ルール、成果物のアウトプットルールは本番と同様になってます。
実行環境やキャッシュの有無での差異が生じないように、 CircleCI を用いたコンテナ環境上で、 webpack 4 / webpack 5 のそれぞれのブランチでのジョブを確認します。
ランダムにサンプリングし、ビルド時間の平均値をとったところ、以下のような結果になりました。
webpack 4.x: 54秒
webpack 5.x: 36秒
正直どのあたりの改修が効いたのかはわかりませんが、実に1/3 ものビルドコストが削減できました。
まとめ
本記事のように、大きな基盤改善は行わずに、 webpack のバージョンを上げるだけでも、ビルドコストを大きく削減することができました。
とはいえ、それでも 36 秒もの時間がかかっている事実から、既に TeachmeBiz は webpack で開発をするには大きくなりすぎた印象も受けます。
そこで、次回は Vite を始めとした、話題の esbuild を用いた爆速開発環境を構築し、開発環境と本番環境でそもそも基盤を分けるというアプローチにもトライしてみようと考えています。
最後に
スタディストでは、こういった技術基盤の改善にも力を入れています。
今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているため、是非ご興味がありましたら下記リンクより、よろしくおねがいします。

BtoB SaaS を扱うマイクロサービス開発チームのWebエンジニア募集 by 株式会社スタディスト
BtoB SaaS を扱う動画編集機能開発チームのWebエンジニア募集 by 株式会社スタディスト

webpack 5 に移行しました was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

webpack 5 に移行しました

スタディスト 開発部 技術支援グループの笹木(<a href="https://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。技術支援グループ(旧 開発基盤チーム) では、開発チームを横断した技術的なサポートや、生産性向上のための仕組み作りを行っています。前回、以下の記事にて、弊社でのフロントエンド技術の変化をご紹介致しました。<a href="https://medium.com/studist-dev/frontend-team-at-studist-a91580d97bb7">移り変わりの早いフロントエンドに対するスタディストの取り組み</a>今回は、上記記事でも簡単にご紹介させていただいた、<a href="https://storybook.js.org/">Storybook</a> のバージョンを 5.x から 6.1 にアップグレードしつつ、レガシー化した既存コードの全リプレイスを行うことで、フロントエンドの開発体験を向上させた 取り組みについて、詳細をお話致します。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*vBsTs3N8I6qOyIE91QM6yw.png" /><figcaption>Storybook 6.1 上で動作する Teachme Biz</figcaption></figure><h3>Teachme Biz フロントエンドの事情</h3>スタディストが運営する <a href="https://biz.teachme.jp/">Teachme Biz</a> のWebフロントエンドは、<a href="https://jp.vuejs.org/index.html">Vue.js</a> を用いて実装されており、本記事執筆時点で、430個のコンポーネントを内包しています。各コンポーネントは、Atomic Design パターン を一部アレンジした階層構造となっており、上位のコンポーネントは、下位のコンポーネントを組み合わせて実装されています。そのほかにも、ドメイン、データストアに干渉できるコンポーネントの制限など、いくつかのルールがありますが、詳細は以下スライドでもご紹介しているので割愛致します。<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2Fembed_code%2Fkey%2FH0n4m9HU4YWEAM&amp;display_name=SlideShare&amp;url=https%3A%2F%2Fwww.slideshare.net%2Fshingosasaki3%2Fteachmebiz-188542240&amp;image=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fvuearchitectureforteachmebiz-191030082428-thumbnail-4.jpg%3Fcb%3D1572423947&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=slideshare" width="600" height="500" frameborder="0" scrolling="no"><a href="https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href">https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href</a></iframe>以上のように、大量のコンポーネントが階層管理されており、設計ルールも細かく整備されている以上、コンポーネントの追加改修を闇雲に行うことはできません。Teachme Biz では、これを解決するため、Storybook を用いたコンポーネントのカタログ化を3年ほど前から行ってきました。<ul><li><a href="https://medium.com/studist-dev/storybook-with-vuex-7084bea6b509">実践StorybookでVuexに立ち向かう</a></li><li><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></li></ul>※ 上記関連記事は、一部内容が古くなっております<h3>旧 Storybook の問題点</h3>Storybook によるカタログ化は、Storybook 3.x 系から始まりました。後に 5.x へのアップグレードこそ行いましたが、基本的なストーリーの書き方や、アドオンの活用、運用ルールなどは、依然として 3.x 時代から変化がないままでした。そういった状態のまま、プロダクトや開発チームはスケールし、それに比例してコンポーネント数やソースコードの複雑性も右肩上がりに増えていきました。次第にレガシー化し、惰性で運用されるようになった Storybook には、以下のような問題が現れました。<ul><li>愚直に既存コードをコピペしただけのストーリーが増え続ける</li><li>ストーリーの書き方、方針が実装時期によってバラバラ</li><li>旧バージョンのアドオンに依存したハックが多く、保守が困難</li><li>ストーリー数の増加による、Storybook 全体のパフォーマンス劣化</li><li>スナップショットテストを運用しても、安定しないテストが量産される</li></ul>本体のバージョンアップをすれば、既存の仕組みは動かなくなり、既存コードを直そうとすると、旧バージョンであることが足枷になる。その間も ストーリーは増え続けるという、まさに袋小路な状態となっていました。こういった状態を抜け出し、惰性ではない、開発生産性を高めるための Storybook 運用を取り戻すべく、 Storybook 及びアドオンの最新化と、既存コードの全リプレイスの決意に至りました。<h3>Storybook 及び アドオンの最新化</h3>着手開始時点では、Storybook 6.0 がリリースされたばかりだったため、以下のマイグレーションガイドを参考に、既存の仕組みが動かなくなることを受け入れつつ、マイグレーションを実施しました。<a href="https://storybook.js.org/blog/storybook-6-migration-guide/">Storybook 6 Migration Guide</a>Storybook 6.0 には、パフォーマンス上の課題があり、同じコードでも 5.x よりも遅いという問題がありました。この問題は、続けてリリースされた 6.1 で大きく改善されることがわかったため、α版の段階から採用することで解決しました。<a href="https://storybook.js.org/blog/storybook-6-1/">Storybook 6.1</a><h3>CSF による既存コードのリプレイス</h3>CSF(Component Story Format) は、Storybook 5.2 からサポートされた、 ストーリーを記述するための新しいフォーマットです。<a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">Component Story Format</a>CSFは Storybook 5.2 からサポートされていましたが、3.x 時代からストーリーの書き方を変えていなかった私たちにとっては、6.x と同時に現れた新しい概念です。従来の storiesOf API 方式では、 storiesOf という、Storybook が提供する API をストーリーファイル側から呼び出すことで、ストーリーの定義を Storybook に知らせます。(<a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">コード引用元</a>)<pre>storiesOf(&#39;atoms/Button&#39;, module) .add(&#39;text&#39;, () =&gt; &lt;Button&gt;Hello&lt;/Button&gt;) .add(&#39;emoji&#39;, () =&gt; &lt;Button&gt;😀😎👍💯&lt;/Button&gt;);</pre>対して CSF 形式では、 ES6 modules に基づき、デフォルトエクスポートと名前付きエクスポートを組み合わせることで、宣言的にストーリーを記述することができます。(<a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">コード引用元</a>)<pre>export default { title: &#39;atoms/Button&#39; }; export const text = () =&gt; &lt;Button&gt;Hello&lt;/Button&gt;; export const emoji = () =&gt; &lt;Button&gt;😀😎👍💯&lt;/Button&gt;;</pre>CSF 形式は、上記のようにストーリーファイル自体が Storybook に対して一切依存しないため、Storybook 以外での汎用的なコンポーネントフォーマットとして期待されています。また、名前付きエクスポート時の変数名がそのままストーリー名になるなど、簡易的にストーリーを記述するための仕組みが豊富に備わっているため、少ないコード量で効率的に記述することができます。上記の例は React でしたが、 Vue の場合、以下のようなテンプレートを用いることで、均一なコード品質で様々なストーリーを定義することができます。<pre>import ComponentName from &#39;./ComponentName&#39; export default { title: &#39;ComponentName&#39; }</pre><pre>const Template = (args, { argTypes }) =&gt; ({ components: { ComponentName }, props: Object.keys(argTypes), template: `&lt;ComponentName v-bind=&quot;$props&quot; /&gt;` })</pre><pre>export const Default = Template.bind({}) Default.args = { props1: true }</pre><pre>export const Custom = Template.bind({}) Custom.args = { ...Default.args, props2: false }</pre>上記は、 ComponentName というコンポーネントに対して Default Custom という名前の2種類のストーリーを定義します。 Default と Custom は、同じコンポーネントを描画しますが、割り当てる props が異なります。また、 <a href="https://storybook.js.org/docs/vue/essentials/controls">addon-controls</a>と組み合わせることで、上記の形式で指定した props を、Storybook 上で動的に切り替えることも容易に実現できます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/496/1*EzRg5GYLbMC6JnO8wgCzHA.gif" /><figcaption>CSF を使った props を動的に書き換えるストーリー</figcaption></figure>こういった Storybook における頻出パターンを CSF では手軽に書けるようになったため、リプレイス作業が想定よりも大幅に楽になりました。なお、CSF 及び Storybook 6 の基本的な使い方については、手前味噌ではありますが、別途記事を投稿しているので気になる方はご参照ください。<a href="https://zenn.dev/sa2knight/books/aca5d5e021dd10262bb9">Vue と CSF によるモダンな Storybook 6 のはじめかた</a>リプレイスにあたっては、既存のストーリーをそのまま CSF で書き直すだけでなく、以下のような新しい基準を設け、必要十分なだけ作成するようにしました。<ul><li>見た目に大きな変化を与える Props がある場合はストーリーを分ける</li><li>インタラクションに変化を与える Props については考慮しない</li><li>(addon-actions などを用いた) イベント(emit) への対応は不要</li><li>上位コンポーネントと密で、固有の状態を持たないコンポーネントは対応しない</li><li>グローバルストアを参照し、それによって見た目が大きく変わる場合、ストアのモックを活用する</li></ul>いずれも見た目の変化に注目しているのは、デザイナーとのコラボレーションや、スナップショットテストでの活用を意識しているためです。振る舞いに関しては E2Eテストを別途管理しているため、Storybook では重要視していません。以上のような方針とストーリーのテンプレートまで出来上がってしまえば、残りのリプレイス作業は人海戦術です。方針と手順を開発チームに共有し、少しずつ協力をお願いすることで、252 種類のストーリーを、通常業務を止めずに、2週間程度で完了することができました。<h3>CSF を応用した Storybook の活用術</h3>前項でご紹介した、CSF を用いることで、ストーリーを描画する以外にも、Storybook を用意に応用できるようになりました。今回は、その中でも以下の二つの仕組みをご紹介します。<ul><li>Storybook 内での vue-i18n の locale 切り替え</li><li>Storybook 上での vue-router による画面遷移</li></ul><h4>Storybook 内での vue-i18n の locale 切り替え</h4>Teachme Biz では、日本語のほか、英語とタイ語をサポートしており、言語の切り替えはブラウザの設定に基づいて行われます。しかし、翻訳漏れの確認や、言語ごとにレイアウト崩れが無いかを検証するために、いちいちブラウザの設定を切り替えるのは非効率です。そこで、以下のように Storybook 上のツールバーから、容易に言語を切り替えられるようにしました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/664/1*jPL1zujZ_pY_aTG5-h-ljw.gif" /><figcaption>Storybook 上のツールバーから言語を切り替えるデモ</figcaption></figure>これまでも同様の仕組みは提供していましたが、 <a href="https://www.npmjs.com/package/@storybook/addon-knobs">addon-knobs</a> を使った、ややハックな仕組みにしていたため、メンテナンスがしづらい問題がありました。Storybook 6.0 からは CSF のような宣言的な記述で、 Storybook 全体の設定を .storybook/preview.js に書けるようになり、以下のようなコードを export するだけで、ツールバーに言語を選択するメニューが追加されます。<pre>export const globalTypes = { locale: { defaultValue: &#39;ja&#39;, toolbar: { icon: &#39;globe&#39;, items: [&#39;ja&#39;, &#39;en&#39;, &#39;th&#39;] } } }</pre>上記 globalTypes で設定されたパラメータ(≒現在選択中の言語) は、<a href="https://storybook.js.org/docs/react/writing-stories/decorators">デコレータ関数</a>から参照することができるため、 vue-i18n を設定し直した Vueコンポーネントで、ストーリーをラップすることで、選択中の言語でストーリーを描画することができます。<pre>(story, context) =&gt; { i18n.locale = context.globals.locale return { i18n, router: new VueRouter({}), store: new Vuex.Store(storeOption), template: `&lt;story /&gt;` } },</pre><h4>Storybook 上での vue-router による画面遷移</h4>Storybook はコンポーネントカタログ用のツールではありますが、擬似的にアプリケーションをStorybook上で動かしつつ、サーバサイドと関わる <a href="https://vuex.vuejs.org/">Vuex</a> をモックすることで、サンドボックス上での画面遷移からデータの表示までを実現することができます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*h3eIzaEWZ93fy8hZF6x90g.gif" /><figcaption>Storybook の中で縦横無尽に画面遷移する図</figcaption></figure><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a>Vuex のモック方法については、上記記事で紹介されている当時の方法そのままなので割愛しますが、<a href="https://router.vuejs.org/">vue-router</a> 用のルーティング設定を元に、CSF を使うことで効率よくページ単位のストーリーを作ることができました。<pre>const load = (name, params = {}, query = {}) =&gt; { return () =&gt; ({ components: { App }, template: `&lt;App :requireAuth=&quot;false&quot; /&gt;`, router: new VueRouter({ routes, mode: &#39;hash&#39; }), created() { this.$router.push({ name, params, query }) } }) }</pre><pre>export const PageA = load(&#39;PageA&#39;) export const PageB = load(&#39;PageB&#39;) export const PageC = load(&#39;PageC&#39;)</pre>App は Vueアプリケーションのルートコンポーネントで、いずれのページも App をそのまま描画します。異なるのは、それぞれ load 関数で指定されたページ名を使って、 App 生成時に、それぞれのページに遷移させることで、それぞれのページを描画してくれるストーリーを動的に生成できるようになりました。<h3>残された課題</h3>ここまでの改修で、開発者にとって開発及び検証しやすい Storybook を取り戻すことが完了したと言えます。しかし、Storybook と Atomic Design という組み合わせで開発しているにも関わらず、エンジニアとデザイナーの協業がイマイチ出来ていないという課題感が現れてきました。この課題解決のためには、<a href="https://www.figma.com/">Figma</a> と Storybook を連動させるといった仕組み的なアプローチから、デザイナーが Vue の世界に踏み込んだり、エンジニアがデザインに関与する、いわゆるクロスファンクショナル化など、色々な策は考えられます。いずれにしても、技術支援グループとしては引き続き、技術の力でその足がかりをサポートできたらと考えているため、今後も Storybook の整備は続きそうです。スタディストでは現在、手順書作成・共有サービス Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。本記事のような、課題に対して自発的に技術で向き合える職場ですので是非！<a href="https://www.wantedly.com/companies/studist/projects">株式会社スタディストの募集・採用・求人情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=42da05471e7d" width="1" height="1" alt=""><hr><a href="https://studist.tech/upgrade-to-storybook-6-42da05471e7d">Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

スタディスト 開発部 技術支援グループの笹木(@s_sasaki_0529) です。
技術支援グループ(旧 開発基盤チーム) では、開発チームを横断した技術的なサポートや、生産性向上のための仕組み作りを行っています。
前回、以下の記事にて、弊社でのフロントエンド技術の変化をご紹介致しました。
移り変わりの早いフロントエンドに対するスタディストの取り組み
今回は、上記記事でも簡単にご紹介させていただいた、Storybook のバージョンを 5.x から 6.1 にアップグレードしつつ、レガシー化した既存コードの全リプレイスを行うことで、フロントエンドの開発体験を向上させた 取り組みについて、詳細をお話致します。
Storybook 6.1 上で動作する Teachme Biz
Teachme Biz フロントエンドの事情
スタディストが運営する Teachme Biz のWebフロントエンドは、Vue.js を用いて実装されており、本記事執筆時点で、430個のコンポーネントを内包しています。
各コンポーネントは、Atomic Design パターン を一部アレンジした階層構造となっており、上位のコンポーネントは、下位のコンポーネントを組み合わせて実装されています。
そのほかにも、ドメイン、データストアに干渉できるコンポーネントの制限など、いくつかのルールがありますが、詳細は以下スライドでもご紹介しているので割愛致します。
https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href
以上のように、大量のコンポーネントが階層管理されており、設計ルールも細かく整備されている以上、コンポーネントの追加改修を闇雲に行うことはできません。
Teachme Biz では、これを解決するため、Storybook を用いたコンポーネントのカタログ化を3年ほど前から行ってきました。

実践StorybookでVuexに立ち向かう
Storybookの可能性を見せびらかしたい

※ 上記関連記事は、一部内容が古くなっております
旧 Storybook の問題点
Storybook によるカタログ化は、Storybook 3.x 系から始まりました。後に 5.x へのアップグレードこそ行いましたが、基本的なストーリーの書き方や、アドオンの活用、運用ルールなどは、依然として 3.x 時代から変化がないままでした。
そういった状態のまま、プロダクトや開発チームはスケールし、それに比例してコンポーネント数やソースコードの複雑性も右肩上がりに増えていきました。
次第にレガシー化し、惰性で運用されるようになった Storybook には、以下のような問題が現れました。

愚直に既存コードをコピペしただけのストーリーが増え続ける
ストーリーの書き方、方針が実装時期によってバラバラ
旧バージョンのアドオンに依存したハックが多く、保守が困難
ストーリー数の増加による、Storybook 全体のパフォーマンス劣化
スナップショットテストを運用しても、安定しないテストが量産される

本体のバージョンアップをすれば、既存の仕組みは動かなくなり、既存コードを直そうとすると、旧バージョンであることが足枷になる。その間も ストーリーは増え続けるという、まさに袋小路な状態となっていました。
こういった状態を抜け出し、惰性ではない、開発生産性を高めるための Storybook 運用を取り戻すべく、 Storybook 及びアドオンの最新化と、既存コードの全リプレイスの決意に至りました。
Storybook 及び アドオンの最新化
着手開始時点では、Storybook 6.0 がリリースされたばかりだったため、以下のマイグレーションガイドを参考に、既存の仕組みが動かなくなることを受け入れつつ、マイグレーションを実施しました。
Storybook 6 Migration Guide
Storybook 6.0 には、パフォーマンス上の課題があり、同じコードでも 5.x よりも遅いという問題がありました。この問題は、続けてリリースされた 6.1 で大きく改善されることがわかったため、α版の段階から採用することで解決しました。
Storybook 6.1
CSF による既存コードのリプレイス
CSF(Component Story Format) は、Storybook 5.2 からサポートされた、 ストーリーを記述するための新しいフォーマットです。
Component Story Format
CSFは Storybook 5.2 からサポートされていましたが、3.x 時代からストーリーの書き方を変えていなかった私たちにとっては、6.x と同時に現れた新しい概念です。
従来の storiesOf API 方式では、 storiesOf という、Storybook が提供する API をストーリーファイル側から呼び出すことで、ストーリーの定義を Storybook に知らせます。(コード引用元)
storiesOf('atoms/Button', module)
 .add('text', () => <Button>Hello</Button>)
 .add('emoji', () => <Button>😀😎👍💯</Button>);
対して CSF 形式では、 ES6 modules に基づき、デフォルトエクスポートと名前付きエクスポートを組み合わせることで、宣言的にストーリーを記述することができます。(コード引用元)
export default { title: 'atoms/Button' };
export const text = () => <Button>Hello</Button>;
export const emoji = () => <Button>😀😎👍💯</Button>;
CSF 形式は、上記のようにストーリーファイル自体が Storybook に対して一切依存しないため、Storybook 以外での汎用的なコンポーネントフォーマットとして期待されています。
また、名前付きエクスポート時の変数名がそのままストーリー名になるなど、簡易的にストーリーを記述するための仕組みが豊富に備わっているため、少ないコード量で効率的に記述することができます。
上記の例は React でしたが、 Vue の場合、以下のようなテンプレートを用いることで、均一なコード品質で様々なストーリーを定義することができます。
import ComponentName from './ComponentName'
export default { title: 'ComponentName' }
const Template = (args, { argTypes }) => ({
 components: { ComponentName },
 props: Object.keys(argTypes),
 template: `<ComponentName v-bind="$props" />`
})
export const Default = Template.bind({})
Default.args = {
 props1: true
}
export const Custom = Template.bind({})
Custom.args = {
 ...Default.args,
 props2: false
}
上記は、 ComponentName というコンポーネントに対して Default Custom という名前の2種類のストーリーを定義します。 Default と Custom は、同じコンポーネントを描画しますが、割り当てる props が異なります。
また、 addon-controlsと組み合わせることで、上記の形式で指定した props を、Storybook 上で動的に切り替えることも容易に実現できます。
CSF を使った props を動的に書き換えるストーリー
こういった Storybook における頻出パターンを CSF では手軽に書けるようになったため、リプレイス作業が想定よりも大幅に楽になりました。
なお、CSF 及び Storybook 6 の基本的な使い方については、手前味噌ではありますが、別途記事を投稿しているので気になる方はご参照ください。
Vue と CSF によるモダンな Storybook 6 のはじめかた
リプレイスにあたっては、既存のストーリーをそのまま CSF で書き直すだけでなく、以下のような新しい基準を設け、必要十分なだけ作成するようにしました。

見た目に大きな変化を与える Props がある場合はストーリーを分ける
インタラクションに変化を与える Props については考慮しない
(addon-actions などを用いた) イベント(emit) への対応は不要
上位コンポーネントと密で、固有の状態を持たないコンポーネントは対応しない
グローバルストアを参照し、それによって見た目が大きく変わる場合、ストアのモックを活用する

いずれも見た目の変化に注目しているのは、デザイナーとのコラボレーションや、スナップショットテストでの活用を意識しているためです。振る舞いに関しては E2Eテストを別途管理しているため、Storybook では重要視していません。
以上のような方針とストーリーのテンプレートまで出来上がってしまえば、残りのリプレイス作業は人海戦術です。方針と手順を開発チームに共有し、少しずつ協力をお願いすることで、252 種類のストーリーを、通常業務を止めずに、2週間程度で完了することができました。
CSF を応用した Storybook の活用術
前項でご紹介した、CSF を用いることで、ストーリーを描画する以外にも、Storybook を用意に応用できるようになりました。今回は、その中でも以下の二つの仕組みをご紹介します。

Storybook 内での vue-i18n の locale 切り替え
Storybook 上での vue-router による画面遷移

Storybook 内での vue-i18n の locale 切り替え
Teachme Biz では、日本語のほか、英語とタイ語をサポートしており、言語の切り替えはブラウザの設定に基づいて行われます。
しかし、翻訳漏れの確認や、言語ごとにレイアウト崩れが無いかを検証するために、いちいちブラウザの設定を切り替えるのは非効率です。
そこで、以下のように Storybook 上のツールバーから、容易に言語を切り替えられるようにしました。
Storybook 上のツールバーから言語を切り替えるデモ
これまでも同様の仕組みは提供していましたが、 addon-knobs を使った、ややハックな仕組みにしていたため、メンテナンスがしづらい問題がありました。
Storybook 6.0 からは CSF のような宣言的な記述で、 Storybook 全体の設定を .storybook/preview.js に書けるようになり、以下のようなコードを export するだけで、ツールバーに言語を選択するメニューが追加されます。
export const globalTypes = {
 locale: {
 defaultValue: 'ja',
 toolbar: {
 icon: 'globe',
 items: ['ja', 'en', 'th']
 }
 }
}
上記 globalTypes で設定されたパラメータ(≒現在選択中の言語) は、デコレータ関数から参照することができるため、 vue-i18n を設定し直した Vueコンポーネントで、ストーリーをラップすることで、選択中の言語でストーリーを描画することができます。
(story, context) => {
 i18n.locale = context.globals.locale
 return {
 i18n,
 router: new VueRouter({}),
 store: new Vuex.Store(storeOption),
 template: `<story />`
 }
},
Storybook 上での vue-router による画面遷移
Storybook はコンポーネントカタログ用のツールではありますが、擬似的にアプリケーションをStorybook上で動かしつつ、サーバサイドと関わる Vuex をモックすることで、サンドボックス上での画面遷移からデータの表示までを実現することができます。
Storybook の中で縦横無尽に画面遷移する図
Storybookの可能性を見せびらかしたい
Vuex のモック方法については、上記記事で紹介されている当時の方法そのままなので割愛しますが、vue-router 用のルーティング設定を元に、CSF を使うことで効率よくページ単位のストーリーを作ることができました。
const load = (name, params = {}, query = {}) => {
 return () => ({
 components: { App },
 template: `<App :requireAuth="false" />`,
 router: new VueRouter({ routes, mode: 'hash' }),
 created() {
 this.$router.push({ name, params, query })
 }
 })
}
export const PageA = load('PageA')
export const PageB = load('PageB')
export const PageC = load('PageC')
App は Vueアプリケーションのルートコンポーネントで、いずれのページも App をそのまま描画します。
異なるのは、それぞれ load 関数で指定されたページ名を使って、 App 生成時に、それぞれのページに遷移させることで、それぞれのページを描画してくれるストーリーを動的に生成できるようになりました。
残された課題
ここまでの改修で、開発者にとって開発及び検証しやすい Storybook を取り戻すことが完了したと言えます。
しかし、Storybook と Atomic Design という組み合わせで開発しているにも関わらず、エンジニアとデザイナーの協業がイマイチ出来ていないという課題感が現れてきました。
この課題解決のためには、Figma と Storybook を連動させるといった仕組み的なアプローチから、デザイナーが Vue の世界に踏み込んだり、エンジニアがデザインに関与する、いわゆるクロスファンクショナル化など、色々な策は考えられます。
いずれにしても、技術支援グループとしては引き続き、技術の力でその足がかりをサポートできたらと考えているため、今後も Storybook の整備は続きそうです。
スタディストでは現在、手順書作成・共有サービス Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。本記事のような、課題に対して自発的に技術で向き合える職場ですので是非！
株式会社スタディストの募集・採用・求人情報 - Wantedly

Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話 was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話

概要
この記事はCircleCI Advent Calendar 2020の9日目の記事です。
スタディスト開発部の笹木です。今年に入ってからは開発基盤チームという位置づけで、開発環境の整備や、CI含むテスト自動化周りを担当しています。
本記事では、RSpecのテスト実行時間を半減させ、CircleCIの消費クレジットを大幅削減した取り組みについてご紹介します。(消費クレジットについては後述します)
改善の結果が以下のグラフで、定点観測しているジョブの消費クレジットが、ピーク時の半分にまで落とせていることがわかります。もちろんテストコードを減らすといった本末転倒なことはしていません。
RSpecジョブ実行時の、CircleCI消費クレジットを時系列で表したグラフ
実施した取り組みは以下の通りです。

CircleCIの料金体系を知る
問題を認識する
CircleCIの利用状況を可視化する
RSpecの実行状況を可視化する
特に遅いテストをチューニングする
FactoryBotの全体最適化
CI上でのRSpec実行時に、Railsのログを吐かないようにする
並列テストをファイルサイズ別から実行タイミング別に変更
CIでの実行マシンのスペックを下げ、並列数をあげる
可能な限りCircleCIのビルド済みイメージを使用する

0. CircleCIの料金体系を知る
本記事では、CircleCIにおける消費クレジット という概念が大きな役割を持っています。
はじめに消費クレジット含め、CircleCIの料金体系についておさらいします。
クレジットとは?
クレジットは、マシンのタイプとサイズ、Docker レイヤー キャッシュなどの有料機能に基づく使用料の支払いに充てられます。
CircleCIには、Free, Performance, Custom の3段階のプランが用意されており、弊社では Performance プランを利用しています。
Performanceプランは下記表のとおり、「ユーザ数に応じた定額課金」と「クレジットの消費量に応じた従量課金」の組み合わせで料金が確定します。
引用元
ユーザ数についてはCIを利用する開発者の数と同じになりますが、クレジットはCIの実行時間、実行マシンの性能、その他オプション機能の利用によって消費量が決定するため、CIの運用方法次第で大きく変わります。
本記事では、CIを1回まわすごとに消費したクレジット量を消費クレジットと表記し、そこに着目した改善を施します。
1. 問題を認識する
まず、なぜCIを改善しようと動き出したかのキッカケについてです。
それまでは漫然とCIを動くまま使い倒し、テストケースの増加に伴い、CI実行時間及び消費クレジットが増え続けていくことを受け入れていました。 正確に言えば受け入れていたのではなく、問題を認識できていないのでした。
そんなある日、CircleCIのプロジェクトページを眺めていると利用状況のページが目に留まりました。
前年度は6,000,000クレジットぐらいだったのに…
「あれ、なんか今月ものすごい消費クレジットがハネてるな…。」
キッカケとしてはそれだけだったのですが、よく見てみると、今月たまたまハネていたのではなく、今年に入ってから急速に増えていき、半年のスパンで見ると大幅に予算を超えていたことがわかりました。
組織がスケールすればテストの総量及びCI実行回数が増えるため、消費クレジットが右肩上がりになるのは自然です。
しかし、それを考慮しても上がり幅が異常だと気が付きました。
2. CircleCIの利用状況を可視化する
アプリケーションのパフォーマンス改善の世界には、「推測するな、計測せよ」という名言があります。
これは、改善すべき対象を闇雲に改善するのではなく、正しく計測、評価し、目標に向かって最短経路での改善を実現しようという話で、アプリケーションに限らずCI周りの改善でも当てはまると思います。
そこで、まずは現状を可視化することがスタートだと考え、実行に移しました。
CircleCIのAPIでは、Insightsという、ワークフロー及びジョブの実行結果のサマリを取得するエンドポイントが提供されています。
例えば、ワークフロー “test” が定義されており、その中のジョブ “rspec” が、masterブランチで実行された場合のサマリは以下のURLで取得することができます。(リポジトリがGithubでホスティングされている場合)
https://circleci.com/api/v2/insights/github/:organization/:repository/workflows/test/jobs/rspec?branch=master
APIを叩くと、以下のように該当するジョブの「ID」「開始日時」「終了日時」「実行時間」「ステータス」「消費クレジット」を取得することが出来ます。
{
  "next_page_token" : null,
  "items" : [ {
    "id" : "30c1a7f0-1234-5678-9012-4dd8d44ef738",
    "started_at" : "2020-08-11T05:52:04.126Z",
    "stopped_at" : "2020-08-11T05:58:32.723Z",
    "duration" : 388,
    "status" : "success",
    "credits_used" : 417
  } ]
}
上記で言う実行時間(duration)と、消費クレジット(credits_used)が評価の対象になります。
このAPIを定期的に叩くスクリプトをGAS(Google Apps Script)で作成、スプレッドシートで自動集計するようにし、現状の可視化を行えるようにしました。
CircleCI利用状況可視化シートの一部
3. RSpecの実行状況を可視化する
続けて、RSpec によるテストについても、どのテストが遅いのかを可視化します。
RSpec には、 — profile というオプションが用意されており、これを指定して実行することで、特に実行時間がかかっているテストケース及びファイルをプロファイリングすることが出来ます。
Top 100 slowest examples (192.87 seconds, 8.2% of total time):
 HogeController ….
 5.61 seconds ./spec/controllers/hoge/hoge_controller_spec.rb:29
 Foo#Bar ….
 3.32 seconds ./spec/models/foo/bar_spec.rb:48
 Hige#Piyo ……
 3.28 seconds ./spec/models/hige/piyo_spec.rb:53
(中略)
Top 100 slowest example groups:
 Hoge#show
 2.59 seconds average (20.72 seconds / 8 examples) ./spec/requests/api/v2/hoge/show_spec.rb:8
 Fuga#export
 2.23 seconds average (17.86 seconds / 8 examples) ./spec/requests/api/v2/fuga/export_spec.rb:12
 Foo
 1.96 seconds average (13.75 seconds / 7 examples) ./spec/models/foo_spec.rb:5
 Bar
 1.8 seconds average (1.8 seconds / 1 example) ./spec/models/bar_spec.rb:6
 contents#index
(以下略)
このプロファイリングは、1回限りではなく、定期実行して改善の進捗を確認したいので、CIで定期実行している、テストカバレッジ計測ジョブに仕込みます。
bundle exec rspec spec/ --format progress —-profile 100
これでRSpec単体で見たときのパフォーマンスも監視できるようになりました。
4. 特に遅いテストをチューニングする
個々のテストコードをチューニングするよりも、実行基盤やテスト全体の最適化をしたほうが効果的。というのは頭では理解していましたが、前項で個々のテストのパフォーマンスを可視化してみたところ、思った以上に極端に遅いテストというのが多数あることが発覚しました。
一部のテストが極端に遅いという状況は、テストの総実行時間に影響を与えるのはもちろん、後述するタイミングデータに基づいたテストの並列化が正しく機能しない問題も抱えています。
極端に遅いテストには、以下のような特徴があったので、費用対効果を考慮しながら、テストの軽量化に取り組みました。
テスト観点において必要以上のデータが作られている
何をテストするのかを明らかにし、そのための必要十分な量のテストデータのみを作成するように修正します。
意図通りのテストが通ることにだけ安心してコミットしてしまいがちですが、テスト実行時のRailsのログを見ながら、不要なデータが生成されていないかをチェックします。
テスト観点が重複している
テスト観点の重複は、あとからジョインしたメンバーが、元々書かれていたテストコードをコピペして量産する場合などに起こりがちです。
多くの場合はコピペでも十分なテストコードでも、テスト観点を明らかにすることで、「このテストケースと、あそこのテストケースは重複しているな」といった判断が出来ます。
テスト観点が多すぎる
テストデータ生成などの前準備が高負荷なのに、テストの観点が多く、 it あるいは example が大量にあるようなテストの場合、その数だけ前準備処理が走ってしまい、テスト全体が非常に低速になってしまいます。
そういう場合は可読性、パフォーマンスとのトレードオフにはなりますが、 Aggregating Failures を用いて、一つのテストケースで複数の観点をチェックするようにすると良いでしょう。 (※これは比較的妥協案です)
5. FactoryBotの全体最適化
弊社では、RSpecによるRailsアプリケーションのテストのためのファクトリに、FactoryBot を使用しています。
これはActiveRecordによる実データの生成を、手軽かつ柔軟に行うことができるツールで、様々な状況のデータを必要とするリクエストスペックなどでは特に重宝します。
しかし、その柔軟さから、一度作られたファクトリは魔法のように動き、どんなデータが作成されるのかが使い手からは想像がつかなくなってしまう場合があります。
以下は実際にあったファクトリコードを模倣したコードになります。
FactoryBot.define do
  factory :folder do
    name { SecureRandom.hex[0..5] }
    trait :with_users do
      after :create do |instance|
        instance.users.create(FactoryBot.create_list(:user, 5))
      end
    end
  end
end
FactoryBot.create(:folder, :with_users) を実行すると、フォルダ及びそのフォルダに所属しているユーザが5人生成されるというファクトリーです。
お気づきかと思いますが、with_users という trait は、「ユーザが5人参加しているフォルダを作りたい」という非常に限定的な条件下でしか活用できません。
しかし、後からジョインし、既存のテストコードをコピーして新しいテストを書くメンバがいた場合、 「ユーザが1人参加しているフォルダを作りたい」 場面でも、この with_users をつい使ってしまいます。
すると、余分な4人のユーザ(及び中間テーブルレコードなど)が作成されてしまい、冗長なテストデータの生成によってテストコードのパフォーマンスがダウンします。(そしてテストは構わずオールグリーンになるため、この事実に気づきません)
上記コードの場合、trait を以下のように改修することで改善できます。
transient { users_count { 1 } } # 指定できるようにする
trait :with_users do
  after :create do |instance|
    instance.users.create(
      FactoryBot.create_list(:user, users_count)
    )
  end
end
transient を用いて、生成するユーザ数を指定できるようにします。さらに、そのデフォルトを1にすることで、意図せず with_users を使った場合も最小の1人のユーザ生成だけですみます。
また、 「ユーザが5人参加しているフォルダを作りたい」というケースでは、意図するユーザが不足するのでテストが失敗し、明示的にusers_count を指定するように促すことで、常に必要最小限のデータ生成で済ませることができます。(テストコードの書き方次第ではありますが)
上記の例はやや極端ではありましたが、このように意図せずにテストデータを大量生成してしまう罠の潜んだファクトリコードが多々あったため、それらを一掃することで大きく改善することができました。
6. CI上でのRSpec実行時に、Railsのログを吐かないようにする
シンプルながらこれが非常に強力でした。
RSpec では、各テストコードを実行するたびに、多量のデータ参照、作成、更新が行われるため、デフォルトの設定では大量のログがファイルに書き出されることになります。
しかし、CIコンテナ上で吐き出されたRailsログを見る機会というのは、非常に稀で、SSHでアクセスしたときぐらいでしょうか。
そんなエッジケース中のエッジケースのために常に大量のログを出力するというのは非効率だったため、config/environments/test.rb に以下の設定を追加しました。
config.log_level = ENV[‘CI’].present? ? :fatal : :debug
これによって、ローカルマシン上でのテスト時にはログを全て出力し、CI上ではエラー情報以外は出力しないという状況が作れます。
(CI は、CircleCI 側がCI上での実行時に注入してくれる環境変数です)
7. 並列テストをファイルサイズ別から実行タイミング別に変更
CircleCI では、一つのジョブに対して、複数コンテナで並列実行する仕組みが用意されています。(テストの並列実行)
これまでは、ファイルサイズによる分割を行っていましたが、 4. 特に遅いテストをチューニングする によって、ファイルごとの実行時間が均されるようになったため、満を持してタイミングデータに基づく分割 を活用できるようになりました。
— split-by=timings でタイミングデータに基づく分割を実施し、RSpec実行時にはRspecJunitFormatter を使ってテストレポートを生成します。
- run:
 command: |
 TESTFILES=$(circleci tests glob “spec/**/*_spec.rb” | circleci tests split — split-by=timings)
 bundle exec rspec — format RspecJunitFormatter -o test-results/rspec.xml — format progress — $TESTFILES
最後のステップにて、テストレポートをアップロードすることで、次回のテストではこのレポート内容に基づいて最適な分割を行ってくれます。
- store_test_results:
 path: test-results
8. CIでの実行マシンのスペックを下げ、並列数をあげる
CI実行時の消費クレジットは、「実行時間」と「実行マシンの種類、性能」によって決定します。
これまでのRSpecの改善によって、「実行時間」は大きく改善しました。続けて実行マシンの種類、性能について考えます。
弊社ではDockerコンテナを利用してCIを回しているので、Docker環境のマシンスペックと消費クレジットに関する一覧表を公式サイトから引用します。
引用元
さて、デフォルトでは Medium が自動的に選択されるため、クレジットは1分間に10消費されます。弊社ではこれまで10並列でRSpecを実行していたので、1コンテナあたり5分かかるとすると、単純計算で500クレジットを消費します。
しかし、現状のRSpecのボトルネックはあくまで DBなどのディスクI/Oのため、リソースクラスによる違い(CPU,memory) の影響を受けているとは考えにくいです。
そこで、以下のようにリソースクラスを Small に引き下げて、並列数を20に増やします。
parallelism: 20
resource_class: small
実際に試してみると、コンテナの性能は半分にしたのに、RSpecのパフォーマンスは半分どころか、せいぜい20%減程度に収まりました。
並列数は倍にしたので、少ない消費クレジットで、テスト全体の実行時間を短くすることに成功しました。
9. 可能な限りCircleCIのビルド済みイメージを使用する
RSpec 自体のステップが高速化してくると、ボトルネックとなってくるのが最初の環境セットアップです。
特に、リクエストスペックを実行するには、各種DBなどのコンテナも別途用意する必要があり、コンテナイメージのプルに時間がかかるようになります。
並列数を20と言わず、30,40にしていきたいのですが、並列数を増やせば増やすほど、環境構築にかかるクレジットの総量は増していき、対して1コンテナあたりのRSpec 実行時間は限りなく0に近づいていくため、相対的に費用対効果が下がっていきます。(消費クレジット量を増やしてもCI実行時間が変わりにくい)そこで、 MySQL や Redis といった単純なDBコンテナイメージについては、CircleCI のビルド済み Docker イメージ を使用することによって、環境構築の一部の負荷を軽減することができました。
- image: circleci/mysql:5.7.17
- image: circleci/postgres:10.1
- image: circleci/redis:4.0.10
とはいえ、アプリケーションを動かすために特化したコンテナイメージは、ホスティングしているDockerリポジトリサービスからプルする必要があるため、根本的な解決には到達していないのが現状です。
(DLC を使うのです…という声が聞こえてきそうですが、1ジョブあたり200クレジットを継続的に消耗するのは現在の規模からすると躊躇ってしまいます…)
まとめ
本記事では、CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9つの手順を紹介しました。
現状の可視化から始まり、テストコードレベル、実行環境レベル、CI設定レベルまで幅広く調べ、結果につなげることも出来たので、個人的には大変満足し、良い経験が出来たと思っています。
これもひとえに、開発基盤チーム という、「重要だが緊急でない仕事」に集中して取り組める環境があったからだと思います。
そんなスタディストですが、現在、マニュアル作成・共有プラットフォーム Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの募集・採用・求人情報 - Wantedly

CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9の手順 was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9の手順

こんにちは、スタディスト開発部の笹木です。2019/10/30(水) クラウドワークス様のオフィスにて行われた、<a href="https://cw-engineers.connpass.com/event/146975/">Vue.jsアーキテクチャリング勉強会</a> に登壇発表してきましたので、その裏側についてお話致します。<h4>登壇資料</h4><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2Fembed_code%2Fkey%2FH0n4m9HU4YWEAM&amp;display_name=SlideShare&amp;url=https%3A%2F%2Fwww.slideshare.net%2Fshingosasaki3%2Fteachmebiz-188542240&amp;image=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fvuearchitectureforteachmebiz-191030082428-thumbnail-4.jpg%3Fcb%3D1572423947&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=slideshare" width="600" height="500" frameborder="0" scrolling="no"><a href="https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href">https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href</a></iframe><h4>背景</h4>私は元々、サーバサイドエンジニアとしてのキャリアを経て、今年から徐々にフロントエンドにも手を出し始めたため、フロントエンドに至ってはまだまだペーペーなエンジニアです。そんな私ですが、弊社から1名登壇者を募集しているという案内を見て、他のフロントエンジニアに高度な情報戦を仕掛けつつ、今後の糧となることが間違いないという見込みで登壇枠を勝ち取りました。<figure><img alt="" src="https://cdn-images-1.medium.com/max/477/0*OkUw4TkIoLqu0J3I" /><figcaption>高度な情報戦の発端となった発言</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/525/1*cNNUM7JeU35GdhVlmN-ZuQ.png" /><figcaption>Go Bold — 大胆にやろう (メルカリさんのバリュー引用)</figcaption></figure><h4>資料作成という名の歴史の勉強</h4>さて、登壇できることが無事に決まったわけですが、困ったことにテーマはvue.jsアーキテクチャリングについてです。私も今年からフロントエンドのコードを書いているフロントエンジニアの端くれ。弊社におけるフロントエンドのアーキテクチャを理解して実践しているつもりではありましたが、その背景や思想までは全然わかっていなかったのです。したがって、登壇資料を作る以前に、まずは<a href="https://biz.teachme.jp/">TeachmeBiz</a> フロントエンドにおける歴史を知る必要がありました。<h4>歴史を知り、思想を引き継ぐ</h4>TeachmeBizのフロントエンドアーキテクチャの歴史を知るためには、現在のアーキテクチャの基礎を生み出した、伝説のフロントエンジニア(当社比) に協力を仰ぐのが良いでしょう。しかし、あいにく彼は既にスタディストを卒業し、現在は他社で活躍しております。直接協力を仰ぐのは難しい状況ではありましたが、幸いなことに彼はフロントエンドアーキテクチャに関する様々な資料を残していきました。<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fspeakerdeck.com%2Fplayer%2F31f9e17cc8fb4b4ca1a652755f772e58&amp;url=https%3A%2F%2Fspeakerdeck.com%2Fkomiyamast%2Fvuetogong-nizou-tutahurontoentorihureisu1nian-jian&amp;image=https%3A%2F%2Fspeakerd.s3.amazonaws.com%2Fpresentations%2F31f9e17cc8fb4b4ca1a652755f772e58%2Fslide_0.jpg%3F487941&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=speakerdeck" width="710" height="399" frameborder="0" scrolling="no"><a href="https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href">https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href</a></iframe>上記スライドの他、私のスライドでは以下記事を引用していることを強調しています。<ul><li><a href="https://medium.com/studist-dev/ddd-vuex-c47055f6c1ba">ドメイン駆動Vuexで複雑さに立ち向かう</a></li><li><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></li></ul>過去の資料やSlack上での発言を整理しながら、現状のソースコードと見比べることで、今までは何となく従っていただけの設計思想の本質が見えて来ました。これは単に見聞を通じてキャッチアップできるレベルの話でなく、勉強会で大勢の前で発表することを前提として学ぶことで、ごまかしのない、圧倒的な学習になっていました。その一方で、知り得た情報を元にどのような登壇資料を作ったら良いかを考えていくうちに、私は一つの結論にたどり着きました。・・・もう、既存スライドを再上映すれば良いんじゃないかな。<h4>伝説のフロントエンジニア(当社比)の褌で相撲を取るのか</h4>既存スライドを使いつつ、一部スクショやコード例を最近のものに置き換えるだけで、その場を乗り切ることは確かに可能でした。登壇の日が近づくにつれ、私の中の悪魔が囁くんです。「既存の資料使い回すだけで登壇実績作れるなんで楽勝っすなぁ」と。しかし曲がりなりにも、私もプロのフロントエンジニア。ここで既存の資料を使い回して、「これがTeachmeBizのアーキテクチャです(他人事)」と言っているようでは、伝説のフロントエンジニアの遺産をただただ食いつぶして劣化させているだけです。他人の褌で相撲を取っている状態で、とてもプロとは言えませんでした。さらに私の中の僅かな天使がこう囁きました。「過去だけを見るのではなく、未来を見るのです」 私は過去の資料をベースに、現在そして未来を見据えて、資料のフルリプレイスを行うことにしました。<h4>今まででなくこれからの話</h4>過去の資料を整理することで圧倒的な学びを得た私ですが、その学んだ内容をまとめるだけではなく、伝説のフロントエンジニア(当社比)が関与していない、私自身が打ち出した新たな施策についてもスライドに盛り込むようにしました。以下はその一例です。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9ILJigaJD4a8oxXXTb9tRg.png" /><figcaption>タイトルにもアーキテクチャ以上の内容を追加</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ivKFPNUxg9WiZrTy2BUzUg.png" /><figcaption>新たな取組の例</figcaption></figure><ul><li><a href="https://medium.com/studist-dev/sharing-documents-in-pull-request-3409e23ade88">CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう</a></li><li><a href="https://medium.com/studist-dev/internationalization-in-storybook-4be77773494c">Storybookとvue-i18nで多言語確認を容易にしよう</a></li></ul>Vue.jsアーキテクチャリング勉強会というテーマからはやや外れた内容も含んでしまいましたが、これは私の意地でもありました。スタディストは伝説のフロントエンジニア(当社比) 退職後も成長し続けているんだと伝えたいエゴです。結果的に登壇はなかなかの好評を頂けたようで、懇親会でもその辺りの話の深堀りも出来たので大変嬉しく、ためになる経験になりました。関係者の皆様には大変感謝致します。<h4>まとめ</h4><ul><li>勉強会での登壇は自分にとって物凄く勉強になる</li><li>設計思想はその本質を知らないと守ってるつもりでも徐々に破綻する</li><li>プロである自分の成果に拘りを持つ</li></ul><h4>スペシャルサンクス</h4><ul><li>Vue.jsアーキテクチャリング勉強会 関係者各位</li><li>多くの勤務時間を登壇準備に使わせてくれたり、登壇資料のレビューをガッツリやってくれた弊社</li><li>伝説のフロントエンジニア(当社比)</li></ul><h4>最後に</h4>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=73cc2177230" width="1" height="1" alt=""><hr><a href="https://studist.tech/learning-through-presentations-73cc2177230">勉強会登壇を通じて学びを得まくった話</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは、スタディスト開発部の笹木です。2019/10/30(水) クラウドワークス様のオフィスにて行われた、Vue.jsアーキテクチャリング勉強会 に登壇発表してきましたので、その裏側についてお話致します。
登壇資料
https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href
背景
私は元々、サーバサイドエンジニアとしてのキャリアを経て、今年から徐々にフロントエンドにも手を出し始めたため、フロントエンドに至ってはまだまだペーペーなエンジニアです。
そんな私ですが、弊社から1名登壇者を募集しているという案内を見て、他のフロントエンジニアに高度な情報戦を仕掛けつつ、今後の糧となることが間違いないという見込みで登壇枠を勝ち取りました。
高度な情報戦の発端となった発言Go Bold — 大胆にやろう (メルカリさんのバリュー引用)
資料作成という名の歴史の勉強
さて、登壇できることが無事に決まったわけですが、困ったことにテーマはvue.jsアーキテクチャリングについてです。
私も今年からフロントエンドのコードを書いているフロントエンジニアの端くれ。弊社におけるフロントエンドのアーキテクチャを理解して実践しているつもりではありましたが、その背景や思想までは全然わかっていなかったのです。
したがって、登壇資料を作る以前に、まずはTeachmeBiz フロントエンドにおける歴史を知る必要がありました。
歴史を知り、思想を引き継ぐ
TeachmeBizのフロントエンドアーキテクチャの歴史を知るためには、現在のアーキテクチャの基礎を生み出した、伝説のフロントエンジニア(当社比) に協力を仰ぐのが良いでしょう。
しかし、あいにく彼は既にスタディストを卒業し、現在は他社で活躍しております。直接協力を仰ぐのは難しい状況ではありましたが、幸いなことに彼はフロントエンドアーキテクチャに関する様々な資料を残していきました。
https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href
上記スライドの他、私のスライドでは以下記事を引用していることを強調しています。

ドメイン駆動Vuexで複雑さに立ち向かう
Storybookの可能性を見せびらかしたい

過去の資料やSlack上での発言を整理しながら、現状のソースコードと見比べることで、今までは何となく従っていただけの設計思想の本質が見えて来ました。これは単に見聞を通じてキャッチアップできるレベルの話でなく、勉強会で大勢の前で発表することを前提として学ぶことで、ごまかしのない、圧倒的な学習になっていました。
その一方で、知り得た情報を元にどのような登壇資料を作ったら良いかを考えていくうちに、私は一つの結論にたどり着きました。
・・・もう、既存スライドを再上映すれば良いんじゃないかな。
伝説のフロントエンジニア(当社比)の褌で相撲を取るのか
既存スライドを使いつつ、一部スクショやコード例を最近のものに置き換えるだけで、その場を乗り切ることは確かに可能でした。
登壇の日が近づくにつれ、私の中の悪魔が囁くんです。「既存の資料使い回すだけで登壇実績作れるなんで楽勝っすなぁ」と。
しかし曲がりなりにも、私もプロのフロントエンジニア。ここで既存の資料を使い回して、「これがTeachmeBizのアーキテクチャです(他人事)」と言っているようでは、伝説のフロントエンジニアの遺産をただただ食いつぶして劣化させているだけです。他人の褌で相撲を取っている状態で、とてもプロとは言えませんでした。
さらに私の中の僅かな天使がこう囁きました。「過去だけを見るのではなく、未来を見るのです」 私は過去の資料をベースに、現在そして未来を見据えて、資料のフルリプレイスを行うことにしました。
今まででなくこれからの話
過去の資料を整理することで圧倒的な学びを得た私ですが、その学んだ内容をまとめるだけではなく、伝説のフロントエンジニア(当社比)が関与していない、私自身が打ち出した新たな施策についてもスライドに盛り込むようにしました。以下はその一例です。
タイトルにもアーキテクチャ以上の内容を追加新たな取組の例
CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう
Storybookとvue-i18nで多言語確認を容易にしよう

Vue.jsアーキテクチャリング勉強会というテーマからはやや外れた内容も含んでしまいましたが、これは私の意地でもありました。スタディストは伝説のフロントエンジニア(当社比) 退職後も成長し続けているんだと伝えたいエゴです。
結果的に登壇はなかなかの好評を頂けたようで、懇親会でもその辺りの話の深堀りも出来たので大変嬉しく、ためになる経験になりました。関係者の皆様には大変感謝致します。
まとめ

勉強会での登壇は自分にとって物凄く勉強になる
設計思想はその本質を知らないと守ってるつもりでも徐々に破綻する
プロである自分の成果に拘りを持つ

スペシャルサンクス

Vue.jsアーキテクチャリング勉強会 関係者各位
多くの勤務時間を登壇準備に使わせてくれたり、登壇資料のレビューをガッツリやってくれた弊社
伝説のフロントエンジニア(当社比)

最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの会社情報 - Wantedly

勉強会登壇を通じて学びを得まくった話 was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

勉強会登壇を通じて学びを得まくった話

<h4>はじめに</h4>こんにちは、<a href="https://studist.jp/">株式会社スタディスト</a> 開発部Webグループの笹木です。スタディストという社名の由来は Study(学ぶ) + st(人)であり、学び続ける姿勢を重要視しています。そのため、社内勉強会のような長期的な視点で組織及びメンバーが成長するための活動を、業務時間内に行っています。今回はその中でも、毎週水曜日に有志で行っている、技術書の輪読会についてご紹介したいと思います。<h4>輪読の対象書籍</h4>現在輪読を進めている書籍は、<a href="https://www.amazon.co.jp/dp/4798159298/ref=cm_sw_r_tw_dp_U_x_IVrsDb4S42FE3">OAuth徹底入門 セキュアな認可システムを適用するための原則と実践</a> です。本書籍は、OAuth 2.0に焦点を当て、その特性や役割に始まり、実運用上のポイントや起こりうる脆弱性まで、網羅的にハンズオン(JavaScript)を通じて学ぶことが出来る一冊です。<a href="https://www.amazon.co.jp/dp/4798159298/ref=cm_sw_r_tw_dp_U_x_IVrsDb4S42FE3">OAuth徹底入門 セキュアな認可システムを適用するための原則と実践</a><h4>輪読の進め方</h4>スタディストでの輪読の進め方は、本書籍に限らず概ね以下の流れになっています。<ul><li><a href="#23ba">[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく</a></li><li><a href="#0052">[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る</a></li><li><a href="#6a43">[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する</a></li><li><a href="#9548">[当日] 理解を深めたい点について議論する</a></li></ul>各手順について、詳しく紹介致します。<h4>[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく</h4>まず、各々の参加者は業務時間内に書籍を読み進め、自分なりに理解を深めつつ要約した内容のメモを取ります。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Mv52jjACGGCftxGVm41Rsg.png" /><figcaption>1. 参加者は事前に対象書籍の対象範囲を読んでおく(例)</figcaption></figure><h4>[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る</h4>一人で書籍を読み進めるだけでは、理解しきれない点が残ったり誤認してしまったりすることがあります。そういった懸念事項のメモを取っておき当日に備えます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*2aLj8dna2Vv7gG3JS_Eq6w.png" /><figcaption>2. 腹落ちしきれなかった点、議論した点についてメモを取る(例)</figcaption></figure><h4>[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する</h4>同じ書籍であっても、読む際に注力した箇所は異なります。例えば、人によっては書籍外の文献にあたったメモを残していたり、自分とは異なる解釈のメモを残していたりします。そのため、他の人の要約を読み込むことによって、自分にはなかった視点で書籍の内容を理解できるようになります。<h4>[当日] 理解を深めたい点について議論する</h4>主に書籍の内容からだけでは読みきれなかった点について、書籍から得た知識を元に、より理解を深めるために議論を行います。議論は主にホワイトボードを使い、参加者それぞれが図を書いたり説明することで、より知識を身近に、深く理解することができます。<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*D-OIjdDx1E5fWgNMSpWeog.jpeg" /><figcaption>4. 議論したい点について議論する(例)</figcaption></figure>時には、書籍を用いてハンズオンしたコードについても読み合わせ、理論だけではなくコードに起こした場合にどうなるかの理解も深めます。<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href">https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href</a></iframe>以上の手順での輪読を、週1回1~2時間行い、1冊の書籍を数ヶ月かけて深く理解するというのが、現在のスタディストでの輪読活動になります。<h4>最後に</h4>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。輪読活動のように、目標に向かった自己成長していけるような職場ですので、エンジニアとして高みを目指している方々を大募集しています。<a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b20c21bc0e33" width="1" height="1" alt=""><hr><a href="https://studist.tech/studist-reading-party-b20c21bc0e33">スタディスト社内では技術書の輪読会やってます</a> was originally published in <a href="https://studist.tech">スタディスト Tech Blog</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

はじめに
こんにちは、株式会社スタディスト 開発部Webグループの笹木です。
スタディストという社名の由来は Study(学ぶ) + st(人)であり、学び続ける姿勢を重要視しています。そのため、社内勉強会のような長期的な視点で組織及びメンバーが成長するための活動を、業務時間内に行っています。
今回はその中でも、毎週水曜日に有志で行っている、技術書の輪読会についてご紹介したいと思います。
輪読の対象書籍
現在輪読を進めている書籍は、OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 です。
本書籍は、OAuth 2.0に焦点を当て、その特性や役割に始まり、実運用上のポイントや起こりうる脆弱性まで、網羅的にハンズオン(JavaScript)を通じて学ぶことが出来る一冊です。
OAuth徹底入門 セキュアな認可システムを適用するための原則と実践
輪読の進め方
スタディストでの輪読の進め方は、本書籍に限らず概ね以下の流れになっています。

[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく
[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る
[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する
[当日] 理解を深めたい点について議論する

各手順について、詳しく紹介致します。
[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく
まず、各々の参加者は業務時間内に書籍を読み進め、自分なりに理解を深めつつ要約した内容のメモを取ります。
1. 参加者は事前に対象書籍の対象範囲を読んでおく(例)
[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る
一人で書籍を読み進めるだけでは、理解しきれない点が残ったり誤認してしまったりすることがあります。そういった懸念事項のメモを取っておき当日に備えます。
2. 腹落ちしきれなかった点、議論した点についてメモを取る(例)
[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する
同じ書籍であっても、読む際に注力した箇所は異なります。例えば、人によっては書籍外の文献にあたったメモを残していたり、自分とは異なる解釈のメモを残していたりします。そのため、他の人の要約を読み込むことによって、自分にはなかった視点で書籍の内容を理解できるようになります。
[当日] 理解を深めたい点について議論する
主に書籍の内容からだけでは読みきれなかった点について、書籍から得た知識を元に、より理解を深めるために議論を行います。議論は主にホワイトボードを使い、参加者それぞれが図を書いたり説明することで、より知識を身近に、深く理解することができます。
4. 議論したい点について議論する(例)
時には、書籍を用いてハンズオンしたコードについても読み合わせ、理論だけではなくコードに起こした場合にどうなるかの理解も深めます。
https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href
以上の手順での輪読を、週1回1~2時間行い、1冊の書籍を数ヶ月かけて深く理解するというのが、現在のスタディストでの輪読活動になります。
最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。輪読活動のように、目標に向かった自己成長していけるような職場ですので、エンジニアとして高みを目指している方々を大募集しています。
株式会社スタディストの会社情報 - Wantedly

スタディスト社内では技術書の輪読会やってます was originally published in スタディスト Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

スタディスト社内では技術書の輪読会やってます


 これはなに？
Rust が全然わからないフロントエンドエンジニアが、最近のフロントエンド領域への Rust の進出に影響を受け、まずは Rust を学んでみるために JSON フォーマッターを作ってみた記録です。
この記事は、Rust ビギナーが AI に頼りつつ雰囲気で実装したものであり、Rust を体系的に学ぶための内容ではありません。
同じように Rust に興味を持っている方々が、まず何から始めたら良いかの参考や刺激になれば幸いです。

 前提
Rust 自体の学習は事前に行っており、その記録は以下のスクラップにまとめています。
https://zenn.dev/sa2kni...

Rust 入門がてら JSON フォーマッターを書く


 概要
GitHub Actions で Chromatic Visual testing (VRT) の実行タイミングを最適化し、課金額を半分以下に削減した事例を紹介します。

 背景
Chromatic は VRT の導入を簡単にでき、メンテナンスコストも低い便利なツールですが、その利便性と引き換えに、撮影したスクリーンショットの枚数に応じて従量課金が発生します。
この従量課金は比較的高額で、特に頻繁にテストを実行するプロジェクトでは費用が急増する可能性があります。
私が担当しているプロダクトでも、Chromatic を導入した初月から予想以上の請求額となり、急遽コスト削減の対策が...

Chromatic の実行を必要最小限にしてコストを削減する


 概要
本記事は、SmartHR Advent Calendar 2023 シリーズ2 の11日目です。
今回は、React と Webpack で開発している Web アプリケーションのフロントエンドテストフレームワークを Jest から Vitest に移行した理由と、その具体的な作業内容についてまとめました。

 バージョン情報


Vite v5.0.6

Vitest v1.0.2

jest v29.7.0

typescript v5.3.3

webpack v5.89.0

Node.js v20.10.0

yarn v1.22.19

macOS Ventura ...

Vite は使ってないけど Jest を Vitest に移行する


 概要
本記事は、SmartHR Advent Calendar 2023 シリーズ2 の7日目です。
本記事では、Storybook を React プロジェクトで使用した場合に内部的に使用される react-docgen について紹介し、その仕組みを深ぼることで Storybook の理解を深めようという記事です。

 バージョン情報

Storybook v7.6.3 (monorepo)
react-docgen v7.0.1


 Storybook v7.6.0 のリリース
先日、Storybook v7.6.0 がリリースされ、変更内容をまとめたブログが公開されました。
...

Storybook と react-docgen の仕組みを追う


 概要
本記事では、JavaScript モジュールバンドラの一種である、 Rspack について、公式ドキュメントからわかることを要約し、自分なりの所感を付け加えて紹介します。

https://www.rspack.dev/misc/branding.html
※ 本記事は、Webpack に関する最低限の知識を前提としています。
※ 本記事は、2023/03/12 時点の情報であり、古い内容が残っている場合があります

 TL;DR;


Rspack は Webpack との互換性とパフォーマンスを両立したモジュールバンドラ

Webpack より5~10倍高速

Webpac...

Rust + Webpack = Rspack の紹介

想定読者や使い方などについては「はじめに」の章をご覧ください。

Storybook 7 を Vue 3 + TypeScript ではじめよう！


 概要
本記事は、Volar を使って型安全に Vue 3 + TypeScript を書いていたら急に以下の型エラーが発生した問題の調査記録になります。

Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps&lt;HTMLAttributes&lt;HTMLDivElement&gt;, HTMLDivElement&gt;'.
Object literal may only specify known properties, and 'class' does not exist in type...

概要
本記事は、Volar を使って型安全に Vue 3 + TypeScript を書いていたら急に以下の型エラーが発生した問題の調査記録になります。

Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'.
Object literal may only specify known properties, and 'class' does not exist in type...

Volar (Vue 3 + TypeScript) に @types/react が混ざると型エラーになる現象と回避策


 概要
本記事は、Vue 3 で Options API を使用するためのフラグである __VUE_OPTIONS_API__ を無効化した場合の挙動やバンドルサイズの違いについてまとめになります。

 TL;DR
Options API を一切使わないプロジェクトなら、Vue アプリケーションの バンドルサイズを 5.49kB 削減 できました (gzip なら 2.14 kB)

 バージョン情報


vue 3.2.45

vite 4.0.2

@vitejs/plugin-vue 4.0.0

rollup 3.8.0


 Options API と Composition...

Vue 3 で Options API を無効化するという選択肢


 概要
本記事は、HTTP クライアントライブラリである axios の v1.0.0 が満を持してリリースされたため、何がどう変わったのか、マイグレーションしても良いのかについて個人的に調べてまとめた結果になります。

 TL;DR


axios の v1.0.0 は、パッケージのモダン化に向けた節目としてのバージョンともいえる

v1.0.0 では多数のバグ修正と、いくつかの小規模の機能追加がまとめて取り込まれた
破壊的変更や非推奨化は少なからずあるが、基本的な使い方や挙動を大きく変える規模の変更はない
一方で劇的に良くなる変化もないので、急いであげる理由もない
公式マイグレーシ...

axios は v1.0.0 でどう変わるのか


 概要
現状の Next.js は webpack を利用しているため、通常なら Storybook を導入する際はあわせて webpack を使用していますが、 Storybook ぐらいは Vite の爆速HMR を使用したいので差し替えてみた差異の作業メモになります。
!
本記事では Storybook 6.x を使用します。後継の 7.x ではビルダー周りの仕組みが大きく変わるためご注意ください。


 webpack 5 ビルダーのアンインストール
webpack を使って Storybook をビルドしていると思うので、これを削除しちゃいます。
(yarn を使用しますが、...

Next.js アプリの Storybook でも Vite を使いたい


 概要
本記事は、 Vue.js の公式ツールである create-vue によって生成された tsconfig.json を元に、 Vue 3 + TypeScript における、 tsconfig のベストプラクティスを理解しようという内容です。

 注意事項
筆者自身はまだまだ Vue 及び TypeScript の理解が不十分であり、誤った解釈を含んでいる可能性があるのでご注意ください。
なにか間違いなどにお気付きの場合は、コメントまたは GitHub での編集提案を頂けると幸いです。

 create-vue について
create-vue は、Vite ベースの Vue プ...

create-vue で学ぶ tsconfig.json


 概要
本記事は、 Vue.js コアチームメンバーである @antfu7 氏の以下ツイートに対する回答を個人的にまとめたものです。
https://twitter.com/antfu7/status/1567511783832961026

React ユーザーの皆さん、
好奇心で聞くのですが、Vue を使ったり試したりするのを妨げているブロッカーや欠点は何ですか？


 注意事項
対立煽りっぽいタイトルにはなっていますが、個人的な好奇心がモチベーションとなっており、特定の技術を贔屓、批判する意図はありません。
私自身は長らく Vue を愛用しており、業務でも大規模 Vue アプリの...

[Twitter] React ユーザーが Vue を選ばない理由


 概要
本記事は、メタ社(旧 FaceBook) が開発した OSS であるメモリリーク検知ツールである [memlab] をさっそく試してみた記録になります。
公式ドキュメント以上の付加価値はあまりありませんが、ざっくりと雰囲気を掴んでもらって使用を検討して頂ければ幸いです。

 memlabについて
memlab は、 Puppeteer API を用いたシナリオを作成することで、そのシナリオ実行によって発生するメモリリークの検出及びヒープ領域の分析を補助してくれるツールです。
https://facebookincubator.github.io/memlab/
本記事は実際に動...

memlab を使って Web サイトのメモリリークを検出しよう


 概要
本記事では、オープンソースのE2Eテストフレームワークである Cypress の Component Testing を用いて、 Vue 3 のコンポーネントのテストを書く手法及びいくつかのレシピを紹介します。
本記事は Vue を用いていますが、 React でも基本的には同様ですので適宜読み替えてください。
想定読者は主に以下の方々です。

モダンなコンポーネントテストの手法例を知りたい

Cypress を E2E テストで使用しているが、コンポーネントテストでの利用にも興味がある
コンポーネントの最適なテスト手法を探している

基本的には公式ドキュメントの内容をベースに...

Cypress で Vue 3 コンポーネントを楽々テストしちゃおう


 概要
本記事では、 npm や yarn などの、Node.js におけるパッケージマネージャーを自作することで、その仕組みや挙動の理解を深めようという取り組みを整理した記事になります。
想定読者は以下を満たす人です。

普段 npm や yarn などのパッケージマネージャを使用している

package.json 内の dependencies devDependencies ぐらいはわかる
npm リポジトリの構成や、パッケージインストールの仕組みとか全然わからんけど、興味がないこともない
TypeScript のコードをまぁまぁ読み書きできる

筆者自身も上記のレベルのため、...

雰囲気でパッケージマネージャーを作ろう


 概要

自分用に整理しただけ
基本的には公式ドキュメントのチュートリアルから抜粋
普段はVueを書いていて Svelte はド素人の状態で作成したので内容に誤りがあるかも
TypeScript, SvelteKit への言及ナシ


 開発環境構築
多分 Vite が一番早い
yarn create vite my-svelte-app --template svelte
cd my-svelte-app/
yarn install
yarn dev
localhost:3000 でもう動いてる
vscode なら Svelte 用の拡張を入れておけば、シンタックスハイライトやコード...

Svelte 初心者用チートシート


別メディアからの移植記事のため、古い内容を含むことにご注意ください


 対象


RSpec での簡単なテストの書き方は基本的に知っている

rspec-mocks を使ったテストを知らない|知ってるけど雰囲気で使っている

上記に当てはまる私自身が、テストをより効率的に書くために、広く浅くざっくり調べた内容のため、より詳しく知りたい人は公式ドキュメントなどを漁ってください。
※記事中に出てくるコードの多くは、RSpec によるテストコード内で実行されるコードです。周辺のコードは省略するので、適当に文脈から読み取ってください。

 前提

rspec-core (3.7.1)
rsp...

rspec-mocksを使ってテストで上手に手を抜こう


別メディアからの移植記事なので、内容がやや古いのでご注意ください


 TL;TD


package.jsonに記述するフィールドで、peerDependencies で定義したバージョンを満たしてなくても警告を出さなくするためのオプションを設定することができる (2020/05/03時点)
パッケージを公開する人以外はあんまり気にしなくても大丈夫そう


 そもそもpeerDependencies とは
peerDependencies は、あるモジュールXに対するインタフェースを持っており、モジュールXから参照されることを想定するが、モジュールXのどこまでにバージョン互換性を持っ...

package.jsonのpeerDependenciesMetaってなんだ？


 概要
Pinia を用いたグローバルステート管理を、表題の組み合わせで TODO ストアを作るサンプル事例です。
https://github.com/posva/pinia

 Pinia とは
Vue におけるグローバルステート管理といえば、 Vuex であり、現状は Vue 2 向けの Vuex 3 と、 Vue 3 向けの Vuex 4 が主流となっています。
Vue コアチーム及びコミュニティでは現在、 Vuex 5 の仕様を RFC を通して検討、実装している状態になっており、その仕様は従来の Vuex とは大きく異なるものとなっています。
https://github....

Pinia + Vue 3 + TypeScript による次世代のグローバルステート管理


 Chart.js 3 について
!
本記事は vue-chart-js が Vue 3 及び Chart.js 3 に対応していなかった時代の代替策を紹介してますが、 vue-chart-js 4.0.0 からそれらがサポートされたため、多くのケースではそちらで十分となるため、本記事は非推奨になります。

!
本記事は vue-chart-3 の初期バージョンを元に動作確認しています。最新バージョンでは一部使用方法が異なるのでご注意ください

Chart.js 3 は、 Canvas を用いたグラフ描画ライブラリとして人気の高い Chart.js の最新バージョンで、 2021年4月...