tsconfig.json には <a href="https://www.typescriptlang.org/ja/tsconfig#skipLibCheck" target="_blank">skipLibCheck</a> という設定オプションがあります。 
このオプションの挙動やどんな時に設定するかについてまとめました。
<h2 id="skipLibCheckの挙動">skipLibCheckの挙動</h2>
このオプションのデフォルト値は false で true を設定することで <code>*.d.ts</code> ファイルに対する型チェックをスキップすることができます。
次のようなサーバーのコードを考えてみます。
<pre class="language-typescript"><code class="language-typescript">import express from "express";

const app = express();

app.post("/uses/sign_in", (req: express.Request, res: express.Response) => {
 if (req.tokens.includes('abc')) {
 res.sendStatus(200)
 } else {
 res.sendStatus(403);
 }
});

app.listen(3000, () => {
 console.log("Listening on port 3000");
});
</code></pre>
tsconfig.json では <code>skipLibCheck</code> は定義しておらず、デフォルトの false が設定されている状態です。
<pre class="language-json"><code class="language-json">{
 "compilerOptions": {
 "esModuleInterop": true,
 "typeRoots": [
 "node_modules/@types",
 "types"
 ]
 }
}
</code></pre>
<code>req.tokens</code> は次のような型定義ファイルを作成して、 <code>express.Request</code> の型定義を拡張して新たにプロパティを定義しています。この時、 <code>tokens: Array</code> とジェネリクスを指定すべき箇所を誤って指定しているため、型定義エラーが発生しています。
<pre class="language-typescript"><code class="language-typescript">// types/express/index.d.ts
/// &lt;reference types="express" />

// @see: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/method-override/index.d.ts
declare namespace Express {
 export interface Request {
 // Interface Array&lt;T>
 // Generic type 'Array&lt;T>' requires 1 type argument(s).ts(2314)
 tokens: Array;
 }
}
</code></pre>
この状態で、 tsconfig.json にて <code>skipLibCheck: true</code> を設定します。
<pre class="language-json"><code class="language-json">{
 "compilerOptions": {
 "skipLibCheck": true,
 // (省略)
 }
}
</code></pre>
<code>*.d.ts</code> ファイルに対する型チェックがスキップされるのでエラーが消え、正しくない型定義ファイルが存在してもコンパイルエラーが出なくなってしまいました。
<pre class="language-typescript"><code class="language-typescript">declare namespace Express {
 export interface Request {
 tokens: Array;
 }
}
</code></pre>
この状態では <code>req.tokens</code> は <code>any</code> として解釈されます。
<pre class="language-typescript"><code class="language-typescript">// （省略）
app.post("/uses/sign_in", (req: express.Request, res: express.Response) => {
 // (property) Express.Request.tokens: any
 if (req.tokens.includes('abc')) {
 res.sendStatus(200)
 } else {
 res.sendStatus(403);
 }
});
</code></pre>
<h2 id="skipLibCheckのメリット">skipLibCheckのメリット</h2>
挙動を見る限りでは <code>skipLibCheck: true</code> を設定することで、型チェックの精度が下がるデメリットがありましたが <code>skipLibCheck: true</code> を設定するメリットは何なのでしょうか？
アプリケーションが中規模、大規模になり依存するパッケージが増えた時に、それに比例して型定義ファイルが増えていきます。 <code>tsc</code> のデフォルトの挙動では、TypeScriptをコンパイルするときに <code>@types/express</code> などのライブラリの <code>*.d.ts</code> に対しても型チェックを実施するため、コンパイル時間が増加します。 <code>skipLibCheck: true</code> を設定することで、型チェックの精度を犠牲にする代わりにコンパイル時間を削減できます。
<pre class="language-bash"><code class="language-bash"># skipLibkCheck: false
$ yarn tsc --extendedDiagnostics -p ./
Files: 88
Check time: 1.47s
Total time: 2.51s
✨ Done in 2.85s.

# skipLibCheck: true
$ yarn tsc --extendedDiagnostics -p ./
Files: 88
Check time: 0.18s
Total time: 1.17s
✨ Done in 1.49s.
</code></pre>
他のシナリオとしては、複数のパッケージが、それぞれが異なるバージョンの型定義ファイルに依存している（別々のパッケージ <code>@types/react@^16</code> と <code>@types/react@^17</code> に依存しているなど）場合に、同じ型定義ファイルが複数 node_modules にインストールされる場合があります。この時に <code>error TS2300: Duplicate Identifier</code> という型定義の重複エラーが発生してコンパイルに失敗します。
解決策としては、パッケージのバージョンを上げるなどして依存関係を整理して重複を無くす方法があります。しかし、それが難しい場合は <code>skipLibCheck: true</code> を指定することで型定義ファイルの型チェックをスキップすることで、エラーを回避することができます。
<h2 id="さいごに">さいごに</h2>
<code>skipLibCheck</code> は true or false のそれぞれにメリット・デメリットがあるため、プロジェクトで何を優先するかを決めて設定の有無を決めると良いでしょう。

ESLintは毎回プロジェクト開始の最初だけ設定して、その後あまり触ることが無く毎回なんとなくで設定して、新しく設定する時に設定項目を忘れてしまう事が多いので、各設定項目や導入プラグインの目的をちゃんと理解したいと思い、まとめました。

TypeScriptのskipLibCheckを理解する

ESLintをちゃんと理解する

<h2 id="はじめに">はじめに</h2>
年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。その影響でLighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-result.jpg" alt="改善前のLighthouseの結果" width="1522" height="676" />
<h2 id="原因調査">原因調査</h2>
<h3 id="Lighthouseの結果を考察">Lighthouseの結果を考察</h3>
Lighthouseの詳細を見てみると 722.4kb という巨大なJSファイルが配信されていました。「Potential Saving 99.8kb」とあるように、このJFファイルの中の大部分が未使用コードになっています。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-unused-js.png" alt="未使用なJavaScript" width="735" height="385" />
また巨大なjsファイルによりJavaScriptの「Script Evaluation」が 1,835ms と、長時間のレンダリングブロッキングが発生していました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-thread-work.png" alt="メインスレッドの実行時間" width="717" height="406" />
<h3 id="Webpack Bundle Analyzer">Webpack Bundle Analyzer</h3>
先ほどのLighthouseの結果で問題になっていた、巨大なjsファイルは chunks/pages/post/[slug]-xxx.js でした。これは記事の詳細ページでNext.jsのビルドにより生成されたファイルです。このファイルにバンドルされているモジュールを調査して、jsファイルが巨大化している原因を特定します。
Next.jsは内部でビルドにWebpackを利用しているので、<a href="https://github.com/webpack-contrib/webpack-bundle-analyzer" target="_blank">webpack-contrib/webpack-bundle-analyzer</a> を使うことで、生成されたJSファイルのバンドル情報を可視化することができます。
Next.js のプラグインとして <a href="https://github.com/vercel/next.js/tree/canary/packages/next-bundle-analyzer" target="_blank">@next/bundle-analyzer</a> が提供されているので、今回はこちらを導入していきます。
最初にパッケージをインストールします。
<pre class="language-bash"><code class="language-bash">$ yarn add -D @next/bundel-analyzer
</code></pre>
続いて Next.config.js にプラグインを利用する設定を書いていきます。 
環境変数として <code>ANALYZE=true</code> が指定されていた時だけ、bundle-analyzer を実行するようにしています。
<pre class="language-javascript"><code class="language-javascript">const withBundleAnalyzer = require('@next/bundle-analyzer')({
 enabled: process.env.ANALYZE === 'true',
});

const config = {
 // 省略
};

module.exports = withBundleAnalyzer(config);
</code></pre>
次のように実行することで確認ができます。
<pre class="language-bash"><code class="language-bash">$ ANALYZE=true next build
</code></pre>
今後のことも考えて実行コマンドは package.json に登録しておきます。
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "bundle-analyzer": "ANALYZE=true next build"
 }
}
</code></pre>
<h3 id="Webpack Bundle Analyzer の結果を考察">Webpack Bundle Analyzer の結果を考察</h3>
webpack-bundle-analyzer を実行することで、ビルド中にブラウザに可視化された情報が表示されます。 
可視化された結果をみてみると <a href="https://github.com/wooorm/refractor" target="_blank">refractor</a> というモジュールが大部分を占めており、このモジュールの読み込みが今回の問題の原因となっていそうです。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png" alt="bundle-analyzerの結果" width="2876" height="1532" />
<code>yarn.lock</code> を参照すると、 <code>refractor</code> は <a href="https://github.com/react-syntax-highlighter/react-syntax-highlighter" target="_blank">react-syntax-highlighter/react-syntax-highlighter</a> から読み込まれていることが分かりました。
<pre class="language-yaml"><code class="language-yaml">react-syntax-highlighter@^15.4.3:
 version "15.4.3"
 resolved "https://registry.yarnpkg.com/react-syntax-highlighter/-/react-syntax-highlighter-15.4.3.tgz#fffe3286677ac470b963b364916d16374996f3a6"
 integrity sha512-TnhGgZKXr5o8a63uYdRTzeb8ijJOgRGe0qjrE0eK/gajtdyqnSO6LqB3vW16hHB0cFierYSoy/AOJw8z1Dui8g==
 dependencies:
 "@babel/runtime" "^7.3.1"
 highlight.js "^10.4.1"
 lowlight "^1.17.0"
 prismjs "^1.22.0"
 refractor "^3.2.0"
</code></pre>
これでパフォーマンス問題の原因が特定できたので、残りはこの問題を改修していきます。
<h2 id="パフォーマンス改善">パフォーマンス改善</h2>
<code>reflactor</code> には、シンタックスハイライトで利用する言語ごとのjsファイルが含まれており、それらが初回レンダリングのタイミングで全て読み込まれることで、パフォーマンス低下を引き起こしていました。<code>react-syntax-highlighter</code> は動的インポートにも対応しているので、今回は動的インポートによりレンダリングブロックをしないように修正をします。
ただ、最終的に読み込むファイルの転送量が多いことに変わりないので、将来的には別のアプローチで解決したいです。
<pre class="language-typescript"><code class="language-typescript">// import { Prism as SyntaxHilighter } from 'react-syntax-highlighter';
import { PrismAsync as SyntaxHilighter } from 'react-syntax-highlighter';
</code></pre>
動的インポートに変更した後の bundle anlyzer の結果をみると、 <code>refractor-import.xxx.js</code> として <code>refractor</code> の読み込みが新しいチャンクとして切り出されています。<code>[slug]-xxx.js</code> のファイルサイズ も 722.4kb から 216.54kb に削減されています。
<img src="/images/posts/nextjs-perf-improvement/dynamic-import-bundle-analyzer-result.png" alt="動的インポートのbundle-analyzerの結果" width="1514" height="1356" />
修正後の <code>[slug]-xxx.js</code> の中身を見てみると、新たに別の問題が見えてきました。<code>react-syntax-highlighter</code>が全てのテーマファイルを読み込んでいます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result-slug.png" alt="[slug]-xxx.jsのbundle-analyzerの結果" width="2876" height="1530" />
この読み込みも不要なので、必要なテーマファイルだけを読み込むように修正します。
<pre class="language-typescript"><code class="language-typescript">// import { vscDarkPlus as defaultVscDarkPlus } from 'react-syntax-highlighter/dist/cjs/styles/prism';
import defaultVscDarkPlus from 'react-syntax-highlighter/dist/cjs/styles/prism/vsc-dark-plus';
</code></pre>
最終的に <code>[slug]-xxx.js</code> のファイルサイズが 722.kb から 106.5kb と1/7のサイズ削減できました🎉 
これでレンダリングブロッキングの時間が大幅に削減されるので、Ligthouseのパフォーマンス結果も改善されます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-finally.png" alt="最終的なbundle-analyzerの結果" width="1698" height="1492" />
<h2 id="さいごに">さいごに</h2>
今回は1番大きな問題を対象として改善策を実施しましたが、画像の最適化や画像の遅延ロード、その他の不要なJavaScriptファイルの削除と改善項目はまだまだ沢山あります。また、Next.jsのリプレースによって新しく導入したライブラリにより意図せずにパフォーマンス低下が起きてしまったので、今後は <a href="https://github.com/GoogleChrome/lighthouse-ci" target="_blank">GoogleChrome/lighthouse-ci</a> などを導入して継続的にパフォーマンスなどを計測する仕組みを用意していきたいです。

年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。レプレースを実施した結果、Lighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。

Next.jsで作ったブログのパフォーマンス改善

<h2 id="はじめに">はじめに</h2>
TypeScriptをトランスパイルする手段として、主にtscとbabelという二つの選択肢があります。それぞれのツール役割について、どのような違いがあるかをまとめました。 
（webpackを利用する場合は、ts-loaderなどもありますが）
<h2 id="tsc">tsc</h2>
tscはTypeScriptの開発チームが提供しているTypeScriptのトランスパイラで、TypeScriptで書かれたソースコードをJavaScriptへとトランスパイルするツールです。tscは <code>tsconfig.json</code> の <code>target</code> オプションで古いJavaScriptへのトランスパイルをサポートしています。例えば、<code>&quot;target&quot;: &quot;es5&quot;</code> と指定することで、TypeScriptのコードをIE11などでも動くJavaScriptの構文にトランスパイルしてくれます。
しかし、ここで注意する点があります。tscのトランスパイル対象となるのは JavaScriptの構文だけ ということです。具体例として、次の <code>index.ts</code> をトランスパイルした <code>index.js</code> のコードを見てみます。
<pre class="language-typescript"><code class="language-typescript">// tsconfig.json
{
 "compilerOptions": {
 "target": "es5",
 "lib": [
 "ES2015"
 ]
 }
}

// index.ts
const fetchNumber = (): Promise&lt;number> => {
 return new Promise&lt;number>((resolve, reject) => {
 resolve(1);
 });
};

// index.js
var fetchNumber = function () {
 return new Promise(function (resolve, reject) {
 resolve(1);
 });
};
</code></pre>
<code>() =&gt; {}</code> のアロー関数はES2015で導入された構文であるため、IE11では利用できません。そこで、tscがアロー関数を <code>function() {}</code> のようにES5の形式に変換してくれています。ただ、<code>Promise</code> はそのままの形式で残っています。<code>Promise</code>もES2015から導入された仕組みのため、このままでは、IE11では動かすことができません。 
これは、先ほども述べたように tscのトランスパイルは JavaScriptの構文だけ を対象しており、Promiseなどの組み込みオブジェクトは構文でないため、tscのトランスパイル対象から外れてしまいます。
この問題を解決する方法として次に説明する Babel を利用します。
<h2 id="Babel">Babel</h2>
BabelはES2020などの最新のJavaScriptコードをIE11などのブラウザでも動作するJavaScriptコードに変換するトランパイラーです。また構文のトランスパイル以外にも、テストで利用する <code>test-id</code> や デバッグ目的の <code>console.log</code> をプロダクションビルドの時だけ削除するなどのトランスパイルを実行することができます。
<h3 id="Plugins と Presets">Plugins と Presets</h3>
Babelを利用する上で <code>Plugins</code> と <code>Presets</code> という二つの概念だけは把握しておく必要があります。
<code>Plugins</code>はBabelでどのようにコードを変換するかを定義したJSのプログラムです。 
例えば、<code>@babel/plugin-transform-arrow-functions</code> は ES2015から導入されたアロー関数 <code>() =&gt; {}</code> を <code>function() {}</code> というES5の形式に変化するためのプラグインです。Babelを利用する時は、複数のプラグインを組み合わせることで、目的に合わせてコードをトランスパイルしていきます。
実際にES2015の構文をES5にトランスパイルするには多くのプラグインを利用する必要があります。必要なプラグインを一つずつインストールして管理するのは大変です。一つのパッケージとして集約されていると、利用する際にパッケージをインストールするだけで良くなり非常に便利です。
この複数のプラグインを目的に応じてパッケージとして集約する仕組みが <code>Presets</code> です。ユーザーが独自のプリセットを定義することも、他の人が定義したプリセットをインストールして利用することもできます。頻繁に利用するプリセットとしては、Babel公式が提供している <code>@babel/preset-env</code> があります。これは、ES2015以降のJavaScriptの構文をES5にトランスパイルするプラグインを集約したプリセットです。集約されているプラグインは、<a href="https://github.com/babel/babel/blob/master/packages/babel-preset-env/src/available-plugins.js" target="_blank">babel/available-plugins.js at master · babel/babel</a> で確認できます。
<h3 id="TypeScriptのトランスパイル">TypeScriptのトランスパイル</h3>
実際に先ほどのTypeScriptのコードをBabelを利用してIE11でも動作するコードに変換してみます。
最初に必要なパッケージをインストールします。
<ul>
<li>@babel/cli: Babelのcliツール</li>
<li>@babel/core: Babelのコア機能</li>
<li>@babel/preset-env: JavaScriptの構文をトランスパイルする かつ PromiseなどのPolyfillを注入</li>
<li>@babel/preset-typescript: TypeScriptをトランスパイルする</li>
<li>core-js@3: PromiseなどのPolyfillを定義したモジュール</li>
</ul>
<pre class="language-bash"><code class="language-bash"># babelと関連するプリセットのインストール
$ yarn add -D @babel/cli @babel/core @babel/preset-env @babel/preset-typescript
$ yarn add core-js@3
</code></pre>
Babelの設定ファイルはこんな感じです。
<pre class="language-json"><code class="language-json">// babel.config.json
{
 "presets": [
 [
 "@babel/preset-typescript",
 "@babel/preset-env",
 {
 "targets": {
 "ie": "11"
 },
 "useBuiltIns": "usage"
 }
 ]
 ]
}
</code></pre>
TypeScript =&gt; @babel/preset-typescript =&gt; @babel/preset-env =&gt; JavaScript 
という流れでトランスパイルがされていきます。tscと異なる点は、<code>&quot;useBuiltIns&quot;: &quot;usage&quot;</code>を指定することで、<code>targets</code>オプションで 
指定しているブラウザでも動作させるために必要なPolyfillがBabelにより自動で注入されます。
実際に先ほどの <code>index.ts</code> に対してトランスパイルを実行して、出力されるJavaScriptを確認してみます。
<pre class="language-javascript"><code class="language-javascript">// src/index.js
"use strict";

require("core-js/modules/ES2015.promise.js");

require("core-js/modules/ES2015.object.to-string.js");

var fetchNumber = function fetchNumber() {
 return new Promise(function (resolve, reject) {
 resolve(1);
 });
};
</code></pre>
tscと比較して、<code>Promise</code>のPolyfillが別モジュールとして読み込まれています。このようにBabelを利用することで、より柔軟にトランスパイルすることができます。
ただし、ここでも注意が必要でPolyfillを <code>reuire</code> という CommonJS Module 形式で読み込んでいるため、このままではブラウザ上で実行することができません。そのため、このモジュール読み込みを解決するために、モジュールバンドラーのWebpackを利用します。
<h3 id="@babel/preset-typescriptの注意点">@babel/preset-typescriptの注意点</h3>
@babel/preset-typescriptの利用で知っておくべき注意点がいくつかあります。
<h4 id="型チェック">型チェック</h4>
ひとつは、型チェックが実行されないことです。BabelではTypeScriptから型を剥がして、JavaScriptにトランスパイルする作業だけを実行するため、仮に型の不整合が存在しても、トランスパイルが成功してしまいます。
<pre class="language-typescript"><code class="language-typescript">// src/index.ts
const n: number = "hello";
</code></pre>
上記のコードをtscとBabelで実行してみると、Babelでは型エラーが発生せずにトランスパイルが成功します。これでは、TypeScriptを使う一番の目的である型の恩恵が受けられません。
<pre class="language-bash"><code class="language-bash"># tscは型エラーでトランスパイルに失敗する
$ tsc src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.

1 const n: number = "test"
 ~
Found 1 error.

# Babelは型チェックされないのでトランスパイルに成功する
$ yarn babel src/index.ts
(#省略)
✨ Done in 0.54s.
</code></pre>
そのため、Babelでトランスパイルをする場合は、事前にtscで別途型チェックを実施する必要があります。
<pre class="language-bash"><code class="language-bash">$ tsc --noEmit src/index.ts &amp;&amp; babel src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.
</code></pre>
<h4 id="一部機能の非対応">一部機能の非対応</h4>
<code>const enums</code> や デコレーターなど一部のTypeScriptの機能を正常にトランスパイルできない問題があります。対応していないと絶対に困る問題ではないですが、プロジェクトによっては重要な問題となるので、これらの存在を認識していくことが重要です。 
詳細は <a href="https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/" target="_blank">Choosing between Babel and TypeScript</a> を参照してください。
<h2 id="おわりに">おわりに</h2>
Babelで 
今回は @babel/preset-typescript を利用したTypeScriptのトランスパイルを通して、tscとBabelの違いをまとめました。Babelで出力されたファイルはモジュール読み込みを含むため、webpackを利用してモジュール解決をする必要があります。しかし、webpackを利用する場合に、TypeScriptをトランスパイルする方法として <code>ts-loader</code> を使う方法もあります。別の機会にここら辺の話をまとめたいです。
<h2 id="参考">参考</h2>
<ul>
<li><a href="https://www.typescriptlang.org/tsconfig#target" target="_blank">TypeScript: TSConfig Reference - Docs on every TSConfig option</a></li>
<li><a href="https://babeljs.io/docs/en/babel-preset-env#usebuiltins" target="_blank">@babel/preset-env · Babel</a></li>
<li><a href="https://devblogs.microsoft.com/typescript/typescript-and-babel-7/" target="_blank">TypeScript and Babel 7 | TypeScript</a></li>
<li><a href="https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/" target="_blank">Choosing between Babel and TypeScript</a></li>
<li><a href="https://qiita.com/jagaapple/items/ce0da04be28c35dc7d4f#5-interfaces%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8Ftype-aliases%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B" target="_blank">TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita</a></li>
</ul>

TypeScriptをトランスパイルする際のtscとbabelそれぞれの役割をまとめました。

tscとBabel

<img src="/images/posts/wasm-othello/wasm-othello.png" alt="wasm-othello" width="1466" height="1488" />
この記事は <a href="https://qiita.com/advent-calendar/2020/hamee" target="_blank">Hamee Advent Calendar 2020</a> の3日目の記事です。
↓のURLからオセロが遊べるので、ぜひ遊んでみてください！ 
<a href="https://wasm-othello.t-yng.jp/" target="_blank">https://wasm-othello.t-yng.jp/</a>
最上位のレベル6は普通に強いです！CPUのアルゴリズムは自分の普段の思考をベースにしているので、レベル6に勝てない人はリアルで僕とオセロをやっても勝てないレベルです。(多分)
全体のソースコードは <a href="https://github.com/t-yng/wasm-othello" target="_blank">t-yng/wasm-othello</a> に置いてあります。
実装したのは2020年3月頃とかなり前なのですが供養も兼ねて記事にまとめました。 
余談ですが、もうすぐ令和2年が終わるという事実に衝撃を受けながら、この記事を書いています。
<h2 id="はじめに">はじめに</h2>
ブラウザでのWebAssemblyの処理速度がJavaScriptと比較してどれだけ向上するのかを体感したく、オセロのCPUをTypeScriptとWebAssemblyで実装して速度比較をしてみました。
WebAssemblyの実装にはRustを利用しています。Rustを選択した理由は自分がRustを書きたかったのが一番の理由ですが、Rustは言語の仕組みとしてガベージコレクションを持たないため、.wasm にコンパイルしたバイナリコードを軽量化できる特徴があります。
<h2 id="WebAssemblyとは？">WebAssemblyとは？</h2>
<blockquote>
WebAssemblyは、ウェブブラウザのクライアントサイドスクリプトとして動作するプログラミング言語（低水準言語）である。wasmとも称されており、ブラウザ上でバイナリフォーマットの形で実行可能であることを特徴とする。
<a href="https://ja.wikipedia.org/wiki/WebAssembly" target="_blank">WebAssembly - Wikipedia</a>
</blockquote>
バイナリ形式で実行されるので、JavaScriptと比較してより高速な処理速度が実現できます。RustやC/C++やTypeScriptなどの言語からコンパイルできるため、WebフロントエンドのビジネスロジックをJavaScript以外の言語で記述することができるのも一つの特徴です。
<h2 id="WebAssemblyを利用した動作イメージ">WebAssemblyを利用した動作イメージ</h2>
最善手を探索するビジネスロジック部分をRustで実装・コンパイルして .wasm 形式のバイナリコードを出力します。このファイルをJavaScriptファイルを同じ要領で配信して、ブラウザ上で読み込ます。JavaScriptからwasmのバイナリコードを呼び出すことで、一部のビジネスロジックをWebAssemblyで実行できます。
<img src="/images/posts/wasm-othello/wasm.png" alt="WebAssemblyを利用したイメージ図" width="758" height="652" />
<h2 id="ミニマックス法を用いたCPUの実装">ミニマックス法を用いたCPUの実装</h2>
ミニマックス法とは、オセロや将棋などのゲームアルゴリズムを実装する時に利用される事の多い探索手法の一つです。評価関数を用いて盤面の評価値を計算して、自分の手番では評価値が最大となり、相手の手番では評価値が最小となる最善手を選択するアルゴリズムです。
例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のためにAとBの2箇所に絞って探索を行い、2手先までを探索してみます。
<img src="/images/posts/wasm-othello/board.png" alt="盤面" width="401" height="401" />
相手は常に最前手を打つと予測するので、Aを打った場合は最大評価値は100となる位置に石を置いてきます。これに対してBに打った場合は最大評価値は15の位置に石を置いてきます。ここではBに打った方が自分が有利なので、Bを最善手として決定します。
<img src="/images/posts/wasm-othello/board_select_A.png" alt="Aに打った場合" width="860" height="558" />
<img src="/images/posts/wasm-othello/board_select_B.png" alt="Bに打った場合" width="860" height="528" />
このアルゴリズムではよりN手先を探索する方が精度が上がり最善手の精度が高くなります。しかし、探索の深さが増えるほどに探索範囲が爆発的に増えて計算時間が膨大になるため、ある一定の深さで探索を打ち切るという事をします。逆に言えば、処理速度を向上させればそれだけ探索範囲を深くできるためCPUを強くすることができます。
今回のオセロではCPUのレベルを探索の深さと合わせてあるため、レベルを上げるほど探索範囲が増大してCPUの計算時間が処理速度に依存するようになっています。
ミニマックス法は参考となるサイトが沢山あるので、詳細はそちらを参照してください。
<ul>
<li><a href="https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9%E6%B3%95" target="_blank">ミニマックス法 - Wikipedia</a></li>
<li><a href="https://www.webcyou.com/?p=6997" target="_blank">web帳 | 5分で覚えるAI Minimax（ミニマックス）法とalpha-beta法</a></li>
</ul>
実装したオセロのアルゴリズムでは次の評価ルールに基づいて評価関数を実装しました。
<ul>
<li>中盤までは相手の石が多い方が評価値を高くする</li>
<li>後半は自分の石が多い方が評価値を高くする</li>
<li>自分の石が角にある +500</li>
<li>相手の石が角にある - 500</li>
<li>自分の石が角の上下にある -30</li>
<li>相手の石が角の上下にある +30</li>
<li>自分の石が角の斜めにある -100</li>
<li>相手の石が角の斜めにある +100</li>
</ul>
<h2 id="速度結果">速度結果</h2>
TypeScript実装とWebAssembly（Rust実装）での処理速度をグラフで可視化してみました。
<img src="/images/posts/wasm-othello/speed.png" alt="処理速度のグラフ" width="1946" height="1122" />
盤面によっては7~8倍ぐらいの速度差が出ておりWebAssemblyの速度に驚きました。
<h2 id="さいごに">さいごに</h2>
オセロを実装したのは6月ぐらいだと思っていたのですが、実際は3月頃で想像以上の月日の流れの速さに驚きました。Rustで実装してみると所有権やライフタイムなど自分の知らない新しい概念が出てきて面白かったです。
Rustの所有権については、<a href="https://t-yng.jp/posts/rust-ownership/" target="_blank">Rustの所有権と借用を理解する</a>でまとめているので、興味があったら読んでみてください。

WebAssemblyの速度を体感するために、WebAssemblyでオセロのゲームアルゴリズムを実装しました

WebAssemblyでオセロを作った話

GatsbyJSで認証サイトを実装するチュートリアルをやった時のまとめです。

GatsbyJSで認証サイトを実装する

Mateial-UI + webpackの環境で開発を進めている時に、ある時から突然ビルドに時間がかかるようになりました。 
最初は、開発を進めていてファイル数が増えたからビルド時間が増えたのかなと思っていたのですが、それを理由にするには、時間がかかり過ぎていました。
改善のために、調査を進めると Material-UI のアイコン読み込みが原因であることが分かりました。
<h2 id="問題">問題</h2>
問題のコードでは次のようにアイコンを読み込んでいました。
<pre><code>import { AccountCircle } from &quot;@material-ui/icons&quot;;
</code></pre>
上記のパッケージ読み込みをしている1ファイルだけを対象にwebpackでビルドした時のパフォーマンスを計測してみると、1ファイルをビルドをするのに20sほどかかっていました。
※ <a href="https://github.com/stephencookdev/speed-measure-webpack-plugin" target="_blank">speed-measure-webpack-plugin</a> で計測
<pre><code>$ webpack

 SMP ⏱
General output time took 21.63 secs

 SMP ⏱ Loaders
modules with no loaders took 7.4 secs
 module count = 5702
ts-loader took 4.96 secs
 module count = 3

...

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets:
 bundle.js (2.16 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
 main (2.16 MiB)
 bundle.js

WARNING in webpack performance recommendations:
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/
✨ Done in 23.36s.
</code></pre>
<h2 id="原因">原因</h2>
これは不要なファイルを大量に読み込んでいる事が原因でした。
<code>@material-ui/icons/index.js</code>の実装を見てみると、で各アイコンのファイルをrequireしているため、上記のパッケージ読み込みの方法だと、1000個近いアイコンファイルを全て読み込む状態になっていました。
<pre><code>var _AccountCircle = _interopRequireDefault(require(&quot;./AccountCircle&quot;));

var _AccountCircleOutlined = _interopRequireDefault(require(&quot;./AccountCircleOutlined&quot;));
</code></pre>
<h2 id="解決策">解決策</h2>
解決策としてはシンプルに特定アイコンファイルだけ読み込むように修正すればOKです。
<pre><code>import AccountCircle from &quot;@material-ui/icons/AccountCircle&quot;;
</code></pre>
修正版のwebpackのビルド時間を見てみると、無事にパフォーマンスが改善されており、バンドルサイズについても発生していた Warning も消えてくれてました。
<pre><code>$ webpack

 SMP ⏱
General output time took 6.3 secs

 SMP ⏱ Loaders
ts-loader took 5.47 secs
 module count = 3
modules with no loaders took 1.81 secs
 module count = 160

...

✨ Done in 7.69s.
</code></pre>
<h2 id="参考">参考</h2>
<a href="https://dev.to/janpauldahlke/how-to-improve-material-ui-speed-in-react-typescript-1199" target="_blank">How to improve the build speed in React-Typescript, when using material ui - DEV</a>

Mateial-UI + webpack の環境でアイコンのパッケージ読み込み方法がビルド時間に影響する問題について紹介しています。

Material-UI + webpack のアイコン読み込みでハマった

Next.jsでブラウザの Storage オブジェクト を使う時の対応策をまとめています。

Next.jsでStorageオブジェクトを使う

JavaScriptで小数点の桁数を指定してフォーマット表示するには、 <code>toFixed()</code> メソッドを使用します。
<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed" target="_blank">Number.prototype.toFixed() - JavaScript | MDN</a>
<pre class="language-js"><code class="language-js">const number = 12.3456789; 
console.log(seconds.toFixed()) // 1 : 近似値で表現され、引数省略した場合は少数点の桁数は0。
console.log(milliseconds.toFixed(2)) // 12.35 : 近似値で表現される
</code></pre>
個人的な利用ケースとして、パフォーマンス計測で処理時間を表示する時に使うことが多いです。
<pre class="language-js"><code class="language-js">const start = performance.now();
// 何かしらの処理
const end = performance.now();

const seconds = ((start - end) / 1000).toFixed(2);
console.log('処理時間: ', seconds, 's'); // 1.23s 
</code></pre>

JavaScriptで小数点の桁数を指定してフォーマットする方法です。

JavaScriptで小数点の桁数を指定してフォーマット表示

1つのリポジトリ内でフロントエンドとサーバーのコードをディレクトリ分割の形式で管理していましたが、色々と辛くなってきたので、リファクタしてモノリポ化しました。 
その時に考慮した事をまとめています。
※ リファクタ後のリポジトリはプライベートリポジトリなので公開していません。
<h2 id="開発環境">開発環境</h2>
フロントエンドのフレームワークとしてNext.jsを利用しており、外部へのAPIリクエストのプロキシを目的としてBFFをNext.jsのカスタムサーバーとしてexpressを用いて実装しています。
<ul>
<li>BFF: TypeScript, Node.js, express（Next.jsのカスタムサーバー）</li>
<li>フロントエンド: TypeScript, Next.js</li>
</ul>
<h3 id="初期構成">初期構成</h3>
リファクタ前の構成は次のようになっており、ディレクトリ分割によりフロントとサーバーのコードを管理している状態でした。
<pre><code>.
├── .storybook
├── pages
├── public
├── src
│ ├── client
│ ├── common
│ ├── config
│ ├── server
│ └── types
├── stories
├── test
│ ├── src
│ │ ├── client
│ │ ├── common
│ │ └── server
│ └── tsconfig.json
├── next.config.js
├── nodemon.json
├── package.json
├── server.ts
├── tsconfig.json
├── tsconfig.common.json
└── tsconfig.server.json
</code></pre>
<h3 id="初期構成の問題">初期構成の問題</h3>
初期のディレクトリ構成ではルートに大量のファイルやディレクトリが存在していて、初見で見た時にどのファイルやディレクトリがフロントとサーバーのどちらに関係しているのか非常に分かり辛い状態でした。また <code>src</code> や <code>test</code> の中で <code>server</code> と <code>client</code> でディレクトリを分けていますが、フロントとサーバーではTypeScriptの設定が異なるため、tsconfigの設定も複雑化していました。 
※ 説明のために省略していますが、実際は他にもDockerのディレクトリなども存在します。
<h2 id="モノリポ化">モノリポ化</h2>
<h3 id="利用ツールの検討">利用ツールの検討</h3>
今回は yarn workspace のみを利用してモノリポ化を進めました。
モノリポ化で利用されるライブラリとしては <a href="https://github.com/lerna/lerna" target="_blank">lerna</a> が有名ですが、採用を見送りました。今回のケースでは yarn workspace のみで目的が達成できたのと、lerna が BabelなどのOSSプロジェクト（一般に公開する前提のプロジェクト）をモノリポ化する目的で作られているように見え、プライベートなリポジトリでは冗長かつ依存ツールを追加して管理コストが増える事は避けたかったからです。
フロントとサーバーをモノリポで管理するツールとして <a href="https://nx.dev/react" target="_blank">Nx</a> も検討しましたが、簡単に触った感じでは想像以上にフルスタックな印象を受け、Nx のディレクトリ構成に従う必要がありそうで、既存プロジェクトの移行コストが非常に高そうだったので見送りました。
参考として、 <a href="https://codewithhugo.com/yarn-workspaces-application-monorepo/" target="_blank">Yarn Workspaces: monorepo management without Lerna for applications and coding examples</a> とかの記事もありました。
<h3 id="TypeScript Project Reference">TypeScript Project Reference</h3>
モノリポ化にあたり、TypeScript の <a href="https://www.typescriptlang.org/docs/handbook/project-references.html" target="_blank">Project Reference</a> を新たに導入しました。これは、TS3.0 から追加された仕組みでTypeScriptのプロジェクトを独立して管理する事ができます。モノリポによりパッケージを分割するので、合わせてTypeScriptのビルドなどもパッケージ単位で分割したくて導入しました。
モノリポ環境では、@app/web =&gt; @app/server と依存している時に、@app/web を先にビルドすると、@app/server がビルドされておらずモジュール解決に失敗する問題が発生する可能性があります。Project Reference を導入すると、<code>tsc --build</code> と実行することで、@app/web をビルドする時に合わせて @app/server を必要に応じてビルドしてくれるので、依存関係の問題を解消する事もできます。
<h3 id="最終構成">最終構成</h3>
モノリポ化した後のディレクトリ構成は次のようになりました。フロントとサーバーがパッケージ単位で分割されて関連する設定ファイルやディレクトリもパッケージでまとめられたので、非常に見通しが良くなりました。
<pre><code>├── workspaces
| ├── common 複数のパッケージから共通で利用するパッケージ
| │ ├── src ソースコード置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── config 設定ファイルを保持するパッケージ
| │ ├── index.ts バレルファイル
| │ ├── firebase.ts 
| | ├── package.json
| | └── tsconfig.json TypeScriptの設定ファイル
| ├── server サーバー側のパッケージ
| │ ├── src ソースコード置き場
| │ ├── test テストコード置き場
| │ ├── types 型定義ファイル置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── web
| | ├── .storybook Storybookの設定ファイル置き場
| | ├── public 画像などの公開ファイル置き場
| | ├── pages Next.jsのページコンポーネント置き場
| | ├── src
| | ├── stories Storybookのストーリーファイル置き場
| | ├── test テストコード置き場
| | ├── next.config.js Next.jsの設定ファイル
| | ├── nodemon.json 開発環境でのNext.jsのカスタムサーバー自動起動の設定
| | ├── package.json
| | ├── server.ts Next.jsのカスタムサーバー（実装はserverパッケージを参照）
| | ├── tsconfig.json
| | └── tsconfig.server.json
| └── tsconfig.json
└── pakcage.json
</code></pre>
<code>web</code> パッケージの package.json と tsconfig.json の一部です。
<pre class="language-json"><code class="language-json"># web/package.json

{
 "dependencies": {
 "@app/server": "*"
 }
}
</code></pre>
<pre class="language-json"><code class="language-json"># web/tsconfig.json

{
 "extends": "../tsconfig.json",
 "references": [
 { "path": "../server" }
 ]
}
</code></pre>

ディレクトリ分割でフロントエンドとサーバーのコードを管理していたリポジトリをリファクタしてモノリポ化した時のまとめ。

TypeScriptプロジェクトをモノリポ化した時のまとめ

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

記事一覧