複数行のテキストを `...` で省略する便利なCSSプロパティとして [-webkit-line-clamp](https://developer.mozilla.org/ja/docs/Web/CSS/-webkit-line-clamp) があります。

このCSSプロパティは使用方法に制限があり`display`プロパティに `-webkit-box` or `-webkit-inline-box` を設定して、かつ `-webkit-box-orient`プロパティに `vertical` を設定する必要があります。

```css
/* 大抵はこんな感じで指定する */
{
    display: -webkit-box;
    -webkit-box-orient: vertical;
    -webkit-line-clamp: 3;
    overflow: hidden;
}
```

ここで指定する `-webkit-box` の正体は `flex` プロパティのベンダープレフィックスです。  
flexが草案時代に WebKit で `flex` を利用するときに使われていたプロパティです。

情報は[WHATWGのページ](https://compat.spec.whatwg.org/#css-keyword-mappings)を参考にしました。


複数行テキストの省略時に使用される-webkit-boxについて簡単に調べました。

複数行テキストの省略と-webkit-boxについて


新センのスタートアップ企業が開発している物理的なキーの配列を自由に変更できる分割キーボード [DUMANG DK6 Ergo](http://www.beyondq.com/%E8%B6%85%E9%85%B7%E7%A7%91%E6%8A%80-%E6%AF%92%E8%9F%92%E9%94%AE%E7%9B%98-%E6%A8%A1%E5%9D%97%E5%8C%96%E9%94%AE%E7%9B%98-dk6-dumang.html) を購入しました。

この分割キーボードを MacOS 上で使う上でいくつか問題があったので、自分が行ったセットアップの手順をまとめています。  
※ この記事は 2021年01月23日 時点で発生した問題について記載しています。対象のキーボードは開発中のためこの記事をお読みになるタイミングでは状況が改善されている可能性があります。

## キーコンビネーション

### 問題

DK6 Ergo は MacOS で動作させると左右のキーボードのキーの組み合わせの入力ができません。Emacs では `Ctrl+N` で下方向へカーソル移動しますが、これは同じ右側のキーボードにあるキーを同時に押す必要があり `左のCtrl + 右のN` という形でキーを押しても反応してくれません。

### 解決

[Karabiner-Elements]([https://karabiner-elements.pqrs.org/](https://karabiner-elements.pqrs.org/)) をインストールします。特別な設定は不要でアプリケーションを起動するだけで、左右キーボードのキーコンビネーションが動作します。


MacOS で DK6 Ergo をセットアップする


この技術ブログはNetflifyでホスティングをしていますが、前からNetlifyは無料枠だとCDNのエッジサーバーが日本国内にはなくレイテンシーが発生して、遅いという話が気になっていました。

- [Netlifyが日本からだと遅い \- id:anatooのブログ](https://blog.anatoo.jp/2020-08-03)
- [NetlifyからVercelへの移行を検討した話](https://www.suzu6.net/posts/268-blog-server/) 

## 速度検証
同じブログをVercelにもホスティングして、参考記事と同じようにNetlifyとVercelで1.3MBの画像の応答速度を比較してみます。  
※ 検証時間は水曜日の12:00頃に検証しています。

Netlifyは、応答速度: 629ms/req ,転送速度: 2.07MB/sec という結果でした。正直、この数字だけを見ても早いのか遅いのかよく分かっていません。

```
# Netlifyの応答速度（1.3MBの画像をリクエスト）
$ ab -n 10 -c 1 -k https://t-yng.jp/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking t-yng.jp (be patient).....done


Server Software:        Netlify
Server Hostname:        t-yng.jp
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-AES256-GCM-SHA384,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        t-yng.jp

Document Path:          /images/posts/nextjs-perf-improvement/bundle-analyzer-result.png
Document Length:        1337519 bytes

Concurrency Level:      1
Time taken for tests:   6.294 seconds
Complete requests:      10
Failed requests:        0
Keep-Alive requests:    10
Total transferred:      13378950 bytes
HTML transferred:       13375190 bytes
Requests per second:    1.59 [#/sec] (mean)
Time per request:       629.442 [ms] (mean)
Time per request:       629.442 [ms] (mean, across all concurrent requests)
Transfer rate:          2075.71 [Kbytes/sec] received

（省略）
```

Vercelの場合は、応答速度: 172ms/req, 転送速度: 7.5MB/sec となり、Netlifyの約4倍も高速という結果になりました。  
ここまで素直に違いが出ると思わなかったので、驚きました。

```
$ ab -n 10 -c 1 -k https://blog-eta-beryl.vercel.app/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking blog-eta-beryl.vercel.app (be patient).....done


Server Software:        Vercel
Server Hostname:        blog-eta-beryl.vercel.app
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        blog-eta-beryl.vercel.app

Document Path:          /images/posts/nextjs-perf-improvement/bundle-analyzer-result.png
Document Length:        1337519 bytes

Concurrency Level:      1
Time taken for tests:   1.721 seconds
Complete requests:      10
Failed requests:        0
Keep-Alive requests:    10
Total transferred:      13380710 bytes
HTML transferred:       13375190 bytes
Requests per second:    5.81 [#/sec] (mean)
Time per request:       172.050 [ms] (mean)
Time per request:       172.050 [ms] (mean, across all concurrent requests)
Transfer rate:          7594.93 [Kbytes/sec] received

（省略）
 ```

## なぜNetlifyは遅いのか？
最初にも書いたとおり、CDNのエッジサーバーが日本国内になくシンガポールなどの国外のサーバーを経由して配信されるため、その分だけ通信のレイテンシーが発生しているのが原因です。

Netlifyにホスティングしているドメインに対して通信経路を表示してみたら、シンガポールっぽいサーバーにアクセスをしていました。

```zsh
$ traceroute t-yng.jp

traceroute: Warning: t-yng.jp has multiple addresses; using 104.248.158.121
traceroute to t-yng.jp (104.248.158.121), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  2.072 ms  1.227 ms  1.110 ms
 2  192.168.24.1 (192.168.24.1)  1.391 ms  1.580 ms  1.406 ms
 3  153.153.253.241 (153.153.253.241)  6.315 ms  7.216 ms  7.145 ms
 4  153.153.253.133 (153.153.253.133)  5.132 ms  4.885 ms  5.025 ms
 5  118.23.46.65 (118.23.46.65)  7.509 ms  12.750 ms  8.127 ms
 6  180.8.119.137 (180.8.119.137)  8.569 ms  6.889 ms  5.825 ms
 7  153.149.219.49 (153.149.219.49)  14.854 ms  15.650 ms  20.806 ms
 8  153.149.219.146 (153.149.219.146)  22.481 ms  21.862 ms  27.243 ms
 9  ae-12.r02.osakjp02.jp.bb.gin.ntt.net (61.200.80.9)  15.422 ms  18.149 ms  23.293 ms
10  ae-3.r25.osakjp02.jp.bb.gin.ntt.net (129.250.2.129)  17.947 ms
    ae-2.r25.osakjp02.jp.bb.gin.ntt.net (129.250.7.32)  18.441 ms  19.506 ms
11  ae-9.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.2.66)  84.407 ms  90.269 ms  88.346 ms
12  ae-0.a00.sngpsi07.sg.bb.gin.ntt.net (129.250.2.74)  85.529 ms  87.029 ms
    ae-0.a01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.122)  91.914 ms
13  ae-0.digital-ocean.sngpsi07.sg.bb.gin.ntt.net (116.51.17.166)  86.345 ms
    ae-1.digital-ocean.sngpsi07.sg.bb.gin.ntt.net (116.51.17.194)  86.923 ms  88.386 ms
14  138.197.245.9 (138.197.245.9)  90.475 ms * *
```

## Vercelへの移行
### Netlifyとのインテグレーションを解除
最初にNetlifyへの自動デプロイを停止するため、Githubリポジトリのインテグレーションを削除しました。  
自分のGithubリポジトリに移動して、Settings > Integrations > Netlify を選択して削除を実行する。

### Vercelへデプロイ
Next.jsで実装しているので[Next.jsの公式ドキュメント](https://nextjs.org/docs/deployment#vercel-recommended)を参考にして進める。  
基本的にはVercelのページ上でポチポチしてGithubリポジトリをVercelのプロジェクトとしてインポートするだけです。

### Netlifyのカスタムドメインの登録解除
独自ドメインの向き先を Netlify => Vercel に変更する。  
Netlifyではカスタムドメインを設定する為に、ドメイン管理会社側のネームサーバーを変更する必要があった。変更していたネームサーバーをデフォルトのドメイン管理会社のネームサーバーに戻す作業を実施する。  

### Vercelにカスタムドメインを登録
その後、Vercelでプロジェクトを選択して Settings > Domains からカスタムドメインを追加する。  
カスタムドメインの追加後にDNSレコードの設定情報が表示されるので、ドメイン管理会社側にDNSレコードを登録する。

![カスタムドメインの設定画像](/images/posts/netlify-to-vercel/vercel-domains-settings.png)

以上で Netlify => Vercel の移行は完了です。

ページ読み込み時の画像表示を含めたページ読み込みの速度が体感として非常に早くなりました！

**Netlify でのページ読み込み**

![Netlifyでのページ読み込み](/images/posts/netlify-to-vercel/netlify.gif)

**Vercel でのページ読み込み**

![Vercelでのページ読み込み](/images/posts/netlify-to-vercel/vercel.gif)

技術ブログのホスティングをNetlifyからVercelに移行しました

NetlifyからVercelに移行した


先日、TypeScriptのテンプレートリテラル型を使う機会がありました。

## モチベーション
フロントエンドで i18n を導入するために [i18next/i18next](https://github.com/i18next/i18next) を利用して文字列の辞書対応を進めていました。

辞書ファイルを入れ子のオブジェクトとして定義ができますが、キーを指定する場合は `common.badge.required` と指定する必要があります。TypeScripeで実装をするときの問題として、キーの文字列に対して型チェックが有効にならないため、タイポをしても気づかない問題があります。

```typescript
import { t } from 'i18next';

const translation = {
    common: {
        badge: {
            required: '必須',
            optional: '任意'
        }
    }
}

export const resources = {
    ja: {
        translation: translation,
    },
} as const;

i18n.init({
    lng: 'ja',
    resources: resources,
})

// badge => bage とタイポしているが実行時まで気づけない
console.log(t('common.bage.required'));
```

## テンプレートリテラル型で型定義
この問題はテンプレートリテラル型を活用してオブジェクトからキーを `.` で繋いだリテラル型を生成することで解消することができます。

`FlattenKeyOf` のユーティリティ型は型引数としてオブジェクトの型を受け取り、Mapped Types を利用してキーの一覧を取得します。取得したキーに対応する値の型を Conditional Types で判定しオブジェクト型である場合は、キーを `.` で先頭に結合して、対応する値のオブジェクトを `FlattenKeyOf` の型引数に渡して再帰的に呼び出すことで残りのキーを文字列として結合します。値がオブジェクトでない場合はキーをリテラル型として返します。  

`string & K` と書いている部分は `K` が `string | number | symbol` 型として扱われますが、テンプレートリテラル型が受け付ける型はプリミティブ型となっているため、型のミスマッチが発生してエラーが発生するので、Intersection Types を利用して `string` 型であれば `K` を返し違う場合は `never` を返すようにすることで型のエラーを回避しています。

```typescript
// const translation = { link: { top: 'トップページ' }}
// type keys = FlattenKeyOf<typeof translation> = 'link.top'
// FlattenKeyOf<{link: { top: 'トップページへ' }}> = {
//     ['link']: `link.top` <= `link.${FlattenKeyOf<{top: 'トップページへ'}}`
// }['link']                               ^
//                                         |__ 'top' = FlattenKeyOf<{top: 'トップページへ'}> = { ['top']: 'top' }['top']
type FlattenKeyOf<T extends Record<string, unknown>> = {
    [K in keyof T]: T[K] extends Record<string, unknown> ? `${string & K}.${FlattenKeyOf<T[K]>}` : string & K
}[keyof T]

// common.badge.required | common.badge.optional
type ResourceKeys = FlattenKeyOf<typeof messages>;

// 引数のキー文字列が辞書ファイルのキー文字列のユニオン型に限定されるため、型チェックでエラーとなる。
console.log(t<string, ResouceKeys>('common.bage.required'))
```

TypeScriptのテンプレートリテラル型の利用例を紹介します。

TypeScriptのテンプレートリテラル型の利用例


iOS端末ではフォームの入力要素のフォントサイズが16px未満だと、入力要素にフォーカスした時に自動で拡大する仕様があります。  
自動拡大が発生すると、ユーザーに対して拡大された状態を戻す操作を強いてしまうため、ユーザービリティを考慮するとできる限り避けたいです。

## 対応策
### フォントサイズを16px以上にする
入力要素のフォントサイズを 16px 以上にすることで、ブラウザが自動拡大するのを防ぐことができます。  

```css
input, textarea, select {
  font-size: 16px;
}
```

### viewport を設定する
デザインを考えると入力要素のフォントサイズを 16px 未満にしたい状況は往々にして存在します。  
また、入力要素のフォントサイズを `rem` などの相対値で指定していた場合に基準値を変更して予期せずフォントサイズが 16px 未満になる危険性もあるため、フォントサイズを 16px 以上に設定するのは良い解決策とは思えません。

そこで、別のアプローチとして `viewport` の `maximum-scale=1` を設定する方法があります。  
`maximum-scale` の初期値は `1.6` に設定されているため、この値を `1.0` に変更することで、ブラウザの自動拡大が発生しても最大倍率が1倍となるため、拡大表示を防ぐことができます。

```html
<meta name="viewport" content="initial-scale=1.0, width=device-width, maximum-scale=1.0" />
```

## どちらを使うべきか？
フォントサイズを 16px 以上に設定する対応は暗黙的な仕様となり得るので避けたいです。  
また、個人的に入力要素のフォントサイズを 16px にするのは、サイズ的に大きいと感じるのとデザインに制約が発生するので、基本は viewport を設定する方針がベストの対応かなと思います。


iOS端末でフォームの入力要素にフォーカスした時に発生する自動拡大への対応策をまとめています。

iOS端末でのフォームの拡大表示に対応する


tsconfig.json には [skipLibCheck](https://www.typescriptlang.org/ja/tsconfig#skipLibCheck) という設定オプションがあります。  
このオプションの挙動やどんな時に設定するかについてまとめました。

## skipLibCheckの挙動
このオプションのデフォルト値は false で true を設定することで `*.d.ts` ファイルに対する型チェックをスキップすることができます。

次のようなサーバーのコードを考えてみます。

```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");
});
```

tsconfig.json では `skipLibCheck` は定義しておらず、デフォルトの false が設定されている状態です。

```json
{
    "compilerOptions": {
        "esModuleInterop": true,
        "typeRoots": [
            "node_modules/@types",
            "types"
        ]
    }
}
```

`req.tokens` は次のような型定義ファイルを作成して、 `express.Request` の型定義を拡張して新たにプロパティを定義しています。この時、 `tokens: Array` とジェネリクスを指定すべき箇所を誤って指定しているため、型定義エラーが発生しています。

```typescript
// types/express/index.d.ts
/// <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<T>
        // Generic type 'Array<T>' requires 1 type argument(s).ts(2314)
        tokens: Array;
    }
}
```

この状態で、 tsconfig.json にて `skipLibCheck: true` を設定します。

```json
{
    "compilerOptions": {
        "skipLibCheck": true,
        // (省略)
    }
}
```

`*.d.ts` ファイルに対する型チェックがスキップされるのでエラーが消え、正しくない型定義ファイルが存在してもコンパイルエラーが出なくなってしまいました。

```typescript
declare namespace Express {
    export interface Request {
        tokens: Array;
    }
}
```

この状態では `req.tokens` は `any` として解釈されます。

```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);
    }
});
```

## skipLibCheckのメリット
挙動を見る限りでは `skipLibCheck: true` を設定することで、型チェックの精度が下がるデメリットがありましたが `skipLibCheck: true` を設定するメリットは何なのでしょうか？

アプリケーションが中規模、大規模になり依存するパッケージが増えた時に、それに比例して型定義ファイルが増えていきます。 `tsc` のデフォルトの挙動では、TypeScriptをコンパイルするときに `@types/express` などのライブラリの `*.d.ts` に対しても型チェックを実施するため、コンパイル時間が増加します。 `skipLibCheck: true` を設定することで、型チェックの精度を犠牲にする代わりにコンパイル時間を削減できます。

```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.
```

他のシナリオとしては、複数のパッケージが、それぞれが異なるバージョンの型定義ファイルに依存している（別々のパッケージ `@types/react@^16` と `@types/react@^17` に依存しているなど）場合に、同じ型定義ファイルが複数 node_modules にインストールされる場合があります。この時に `error TS2300: Duplicate Identifier` という型定義の重複エラーが発生してコンパイルに失敗します。  

解決策としては、パッケージのバージョンを上げるなどして依存関係を整理して重複を無くす方法があります。しかし、それが難しい場合は  `skipLibCheck: true` を指定することで型定義ファイルの型チェックをスキップすることで、エラーを回避することができます。

## さいごに
`skipLibCheck` は true or false のそれぞれにメリット・デメリットがあるため、プロジェクトで何を優先するかを決めて設定の有無を決めると良いでしょう。


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

TypeScriptのskipLibCheckを理解する

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

## ESLintとは？
ESLint は EcmaScript/JavaScript のリンターツールです。チームでコードの利用規約を決め、各自がルールを守って開発するのは大変です。新しくメンバーが増えたときにも、その人がチームのルールに馴染むまで何度もコードレビューで指摘する必要があるかもしれません。ESLintを導入することで、コードのルールチェックを自動化して、統一性のあるコードを担保することができます。

## ESLintの設定
ESLintは設定ファイルで全てルールのON/OFFなどを設定することができます。ESLintの基本的な設定項目について見ていきます。

[Configuring ESLint - ESLint - Pluggable JavaScript linter](https://eslint.org/docs/user-guide/configuring)

### Rules
`rules` オプションはESLintがどのような構文をエラーとするか無視するかを設定するオプションです。デフォルトで定義されているルールとしては「文末にセミコロンを必須とする」 `semi` などがあります。ユーザーは設定ファイルでこれらのルールを設定することで、自分好みにリンターの挙動をカスタマイズすることができます。  
ルールは `off` or `0` , `warn` or `1` , `error` or `2` を指定することで設定ができます。文字列でも数値でも、どちらを指定しても問題ありません。

ESLintは構文チェックで `error` となるルールが見つかった場合は 0以外のexit code で終了し、 `warn` の場合は警告として出力するが構文チェックとしては通過するようになっています。全てを `error` に設定するのも手ですが、Linterの構文エラーを解消するために思わず時間がかかる場合もあるので、チーム内で相談してルールの厳格性を決めると良いです。

次の例では `"quotes": ["error", "single"]` を指定して `'` を使わない場合に構文エラーとしています。また `"no-unused-var": "warn"` と設定することで、未使用の変数を警告として扱うようにしています。 `off` は次で紹介する `extends` を使った場合などに併用する場合が多いです。

```javascript
// error  Strings must use singlequote  quotes
const name = "taro"
// warning  'age' is assigned a value but never used  no-unused-vars
const age = 10
console.log(name)
```

```json
// .esrintrc
{
	"rules": {
		"quotes": ["error", "single"],
        "no-unused-var": "warn"
    }
}
```

### Extends
`extends` オプションではベースとなる設定を指定することで、その設定を継承することができます。先の `rules` オプションの例では、一つ一つルールを設定していました。しかし、毎回プロジェクトごとにルールを全て設定していくのは大変な作業です。そこで ESLint には公式が推奨しているプリセットが存在します。

`extends` オプションで `eslint:recommended` を指定することで、ベース設定を継承して一括で設定をすることができます。

どのようなルールが設定されるかは [公式ドキュメント]([https://eslint.org/docs/rules/](https://eslint.org/docs/rules/)) を参照すれば確認することができます。

```json
{
	"extends": "eslint:recommended"
}
```

ベースとなる設定で一部のルールを無効にしたい場合には、先ほど説明した `rules` オプションで `off` を指定することで設定できます。

```json
{
	"extends": [
		"eslint:recommended"
	],
	"rules": {
        "no-ununsed-vars": "off"
    }
}
```

`extends` は配列で複数指定することが可能です。 `no-unsued-vars` などのルール設定が重複していた場合は、後から指定した設定で上書きされます。  
次の例では、 `eslint:recommended` で定義されている設定が  `plugin:react/recommended` で定義されている設定で上書きされます。

```json
{
	"extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ]
}
```

### Parser Options

ESLintはデフォルトでES5の構文をサポートしています。ES6以降の構文やJSXの構文を対象にする場合は `parserOptions` で設定します。

ここでは次の3つの項目について説明します。
- ecmaVersion
- sourceType
- ecmaFeatures 

`ecmaVersion` はEcmaScriptのバージョンを指定します。デフォルトの値は 5 です。  
デフォルトの設定で次のコードを構文チェックした場合は `The keyword 'const' is reserved` という構文エラーが発生します。

```javascript
// error  Parsing error: The keyword 'const' is reserved
const hello = () => {
    console.log("hello");
};
```

`ecmaVersion` のを指定すれば、構文チェックする EcmaScript のバージョンを変更できます。

```json
{
	"parserOptions": {
		"ecmaVersion": 2020
	}
}
```

`sourceType` はモジュールのタイプを指定します。デフォルトの値は `"script"` です。

デフォルトの設定で ESLint を利用すると import/export などのESモジュールを利用すると構文エラーとなります。

```javascript
// 'import' and 'export' may appear only with 'sourceType: module'
import { pick } from 'lodash';
```

import/export を利用する場合は `"module"` を指定します。

```json
{
	"parserOptions": {
		"sourceType": "module"
	}
}
```

`ecmaFeatures` は JavaScript で有効にする追加の構文拡張を指定します。

例えば、JSX は JavaScript の構文拡張のため、デフォルトの設定では構文エラーとなります。

```javascript
// error  Parsing error: Unexpected token <
const Hello = ({ name }) => <div>{name}</div>;
```

`"jsx": true` を指定することで、JSX も構文チェックができます。

```json
{
    "parserOptions": {
        "ecmaVersion": 2020,
        "ecmaFeatures": {
            "jsx": true
        }
    }
}
```

### Parser
ESLintはデフォルトで [Espree]([https://github.com/eslint/espree](https://github.com/eslint/espree)) を構文解析のパーサーとして利用しています。TypeScript を構文チェックする場合に type キーワードなどは ECMAScript の構文ではないなため構文解析に失敗します。そのため、 `Parser` オプションで別のパーサーを指定する必要があります。

```typescript
// error  Parsing error: Unexpected token User
type User = {
    name: String;
}
```

TypeScriptの構文解析する場合は @typescript-eslint/parser をパーサーを指定します。

```bash
$ yann add -D typescript @typescript-eslint/parser
```

```json
{
  "parser": "@typescript-eslint/parser"
}
```

### Processor
一部のプラグインは特定の機能としてプロセッサーを提供しています。プロセッサーは Markdown ファイルから JavaScript のコードを抜き出して ESLint をかけたりできます。  
例えば、特定のファイルパスで一部のプラグインを無効にする [mradionov/eslint-plugin-disable](mradionov/eslint-plugin-disable) では、次のように `processer` オプションでプロセッサーを指定します。

```json
{
    "plugins": ["react", "disable"],
    "processor": "disable/disable",
    "overrides": [
        {
            "files": ["tests/**/*.test.js"],
            "settings": {
                "disable/plugins": ["react"]
            }
        }
    ]
}
```

### Environments
ブラウザや jest などのグローバル変数や関数を定義済みとして認識するための設定です。  
例えば、jest ではグローバル関数として `describe` や `it` などの関数が定義されますが、ESLint はその関数が定義されていることを認識することができません。 `no-undef` のルールを有効にした状態で、jestのコードを構文チェックを未定義のエラーが発生します。

```javascript
// error  'describe' is not defined  no-undef
describe("test", () => {
	// error  'it' is not defined  no-undef
    it("test", () => {});
});
```

```json
{
    "parserOptions": {
        "ecmaVersion": 6
    },
    "rules": {
        "no-undef": "error"
    },
}

```

`env` オプションで `jest` を設定することで `describe` などのグローバル関数が定義済みであることを ESLint に伝えることで、構文エラーを解消することできます。  
設定可能な環境の一覧は [公式のページ]([https://eslint.org/docs/user-guide/configuring#specifying-environments](https://eslint.org/docs/user-guide/configuring#specifying-environments)) で確認できます。

```json
{
  "env": {
    "jest": true,
  }
}
```

### Globals
環境に依存しない独自に定義したグローバル変数をESLintに認識させるための設定です。  
値として `writable` , `readonly` , `off` が設定できます。

```javascript
// error  'bar' is not defined  no-undef
bar = "bar"
// error  'hoge' is not defined  no-undef
console.log(hoge)
```

```json
{
    "rules": {
        "no-undef": "error",
    "no-global-assign": "error"
    },
    "env": {
        "browser": true
    }
}
```

`writable`, `readonly` は定義済みのグローバル変数に対しての可能な操作を表しています。グローバル変数を上書きする事はほぼ無いのと、そもそも上書き自体がバッドプラクティスなので、基本的には `readonly` を指定すれば大丈夫です。

```javascript
// "readonly" と指定したグローバル変数を上書きしているので、まだ構文エラーが発生している。
// error  Read-only global 'bar' should not be modified  no-global-assign
bar = "bar"
console.log(hoge)
```

```json
// .eslintrc
{
    // (省略)
	"globals": {
		"hoge": "readonly",
		"bar": "readonly"
    }
}
```

上の例では、`no-global-assign` を有効にしている状態で `globals` オプションで `readonly` を設定している `bar` のグローバル変数に対して上書きを実行しており、ESLint の構文エラーが発生しています。  
グローバル変数を上書きする場合は `writable` を指定することで、構文チェックのエラーを解消できます。

```javascript
hoge = 'new hoge'
console.log(hoge)
```

```json
// .eslintrc
{
    // (省略)
	"globals": {
		"hoge": "readonly",
		"bar": "writable"
    }
}
```

### Plugins
ESLintでは「JSX が記述されている場合は React モジュールがインポートされていること」などの独自ルールをプラグインという形で組み込むことができます。  
`plugins` オプションでは利用したいプラグインを配列の形で指定します。また、プラグインを利用する場合は、事前にパッケージとしてインストールしておく必要があります。

例として、React の構文チェックプラグインである [yannickcr/eslint-plugin-react]([https://github.com/yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react)) を導入してみます。

最初にプラグインをインストールします。

```bash
$ yarn add -D eslint-plugin-react
```

次にインストールしたプラグインを `plugins` オプションで指定して、使いたいルールを有効化します。
プラグイン名を指定するときに `eslint-plugin` のプレフィックは省略可能です。

```json
{
    // eslint-plugin-react でもOK
	"plugins": ["react"],
	"parserOptions": {
		"ecmaFeatures": {
			"jsx": true
		}
	},
	"rules": {
		"react/jsx-uses-react": "error",
        "react/jsx-uses-vars": "error"
    }
}
```

先の例では `plugins` オプションの例を示すために、敢えて冗長な書き方をしています。プラグインが提供するプリセットの設定をそのまま適用する場合には、次のように `extends` オプションで一括指定することも可能です。

```json
{
	"extends": [
	    "eslint:recommended",
	    "plugin:react/recommended"
    ]
}
```

### Shared Settings
`settins` オプションはESLintのルール実行時に参照される共通の設定値です。独自のカスタムルールから共通の値に参照したい場合などに利用できます。

 [yannickcr/eslint-plugin-react]([https://github.com/yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react)) を利用する場合に次の設定を書く事でReactのバージョンを指定することができます。

```json
{
	"plugins": ["react"],
	"settings": {
		"react": {
			"version": "16.3"
        }
    }
}
```

## Prettierとの併用
Prettier とはコードの自動整形ツールです。

Prettier は `eslint --fix` では整形されないコードも整形してくれるため、ESLint よりも整形ツールとして優れているという利点があります。 次のようなコードは `eslint --fix` は自動整形してくれませんが、 Prettier はコードを自動整形してくれます。

```typescript
// eslint --fix ではこのコードは整形されない
const getAllPostsImpl: GetAllPosts = new GetAllPostsImpl(postsRepository, directoryRepository);
```

```typescript
// prettier だと整形される
const getAllPostsImpl: GetAllPosts = new GetAllPostsImpl(
	postsRepository, 
	directoryRepository
);
```

ESLint と Prettier の併用方法をインターネットで検索すると [eslint-plugin-prettier]([https://github.com/prettier/eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier)) をインストールして、ESLint 上で Prettier を実行する方法を見かけることがあります。しかし、この方法では Prettier を直接実行するよりも処理に時間がかかったり、自動整形されるコードが構文エラーとして表示される問題があり [公式ページ]([https://prettier.io/docs/en/integrating-with-linters.html](https://prettier.io/docs/en/integrating-with-linters.html)) で非推奨とされています。

公式の推奨する方法では [eslint-config-prettier]([https://github.com/prettier/eslint-config-prettier](https://github.com/prettier/eslint-config-prettier)) を導入してPrettierと競合するルールをオフにして、`prettier && eslint` と先に Prettier でコードを整形をした後に ESLint で構文チェックを実行します。

```json
{
	"extends": [
		"eslint:recommended",
		"prettier"
	]
}
```

```bash
# 実行
$ prettier && eslint
```

[Integrating with Linters · Prettier](https://prettier.io/docs/en/integrating-with-linters.html)

## Reactの設定例
インストールするパッケージ

- [yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react)
- [eslint-plugin-react-hooks]([https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks](https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks))

React v17.0 以降を利用する場合は Reactのモジュールをインポートする必要がなくなったので `react/react-in-jsx-scope` を `off` にしておくことをオススメします。

設定ファイル

```json
{
    "plugins": [
        "react-hooks"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
    ],
    "parserOptions": {
        "sourceType": "module",
        "ecmaVersion": 2020
    },
    "env": {
        "browser": true,
        "jest": true
    },
    "rules": {
        "react-hooks/rules-of-hooks": "error",
        "react-hooks/exhaustive-deps": "warn",
        "react/react-in-jsx-scope": "off",
        "react/prop-types": "off",
        "react/display-name": "off",
    }
}
```

## TypeScriptの設定例

インストールするパッケージ

- [@typescript-eslint/pareser]([https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser))
- [@typescript-eslint/eslint-plugin]([https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin))

```bash
$ yarn add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin
```

設定ファイル

```json
{
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parserOptions": {
        "sourceType": "module",
        "ecmaVersion": 2020
    },
    "env": {
        "browser": true,
        "jest": true
    }
}
```

ESLintをちゃんと理解する


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

![改善前のLighthouseの結果](/images/posts/nextjs-perf-improvement/lighthouse-result.jpg)

## 原因調査
### Lighthouseの結果を考察
Lighthouseの詳細を見てみると 722.4kb という巨大なJSファイルが配信されていました。「Potential Saving 99.8kb」とあるように、このJFファイルの中の大部分が未使用コードになっています。

![未使用なJavaScript](/images/posts/nextjs-perf-improvement/lighthouse-unused-js.png)

また巨大なjsファイルによりJavaScriptの「Script Evaluation」が 1,835ms と、長時間のレンダリングブロッキングが発生していました。

![メインスレッドの実行時間](/images/posts/nextjs-perf-improvement/lighthouse-thread-work.png)

### Webpack Bundle Analyzer
先ほどのLighthouseの結果で問題になっていた、巨大なjsファイルは chunks/pages/post/[slug]-xxx.js でした。これは記事の詳細ページでNext.jsのビルドにより生成されたファイルです。このファイルにバンドルされているモジュールを調査して、jsファイルが巨大化している原因を特定します。

Next.jsは内部でビルドにWebpackを利用しているので、[webpack\-contrib/webpack\-bundle\-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer) を使うことで、生成されたJSファイルのバンドル情報を可視化することができます。

Next.js のプラグインとして [@next/bundle-analyzer](https://github.com/vercel/next.js/tree/canary/packages/next-bundle-analyzer) が提供されているので、今回はこちらを導入していきます。

最初にパッケージをインストールします。

```bash
$ yarn add -D @next/bundel-analyzer
```

続いて Next.config.js にプラグインを利用する設定を書いていきます。  
環境変数として `ANALYZE=true` が指定されていた時だけ、bundle-analyzer を実行するようにしています。

```javascript
const withBundleAnalyzer = require('@next/bundle-analyzer')({
    enabled: process.env.ANALYZE === 'true',
});

const config = {
    // 省略
};

module.exports = withBundleAnalyzer(config);
```

次のように実行することで確認ができます。

```bash
$ ANALYZE=true next build
```

今後のことも考えて実行コマンドは package.json に登録しておきます。

```json
{
    "scripts": {
        "bundle-analyzer": "ANALYZE=true next build"
    }
}
```

### Webpack Bundle Analyzer の結果を考察
webpack-bundle-analyzer を実行することで、ビルド中にブラウザに可視化された情報が表示されます。  
可視化された結果をみてみると [refractor](https://github.com/wooorm/refractor) というモジュールが大部分を占めており、このモジュールの読み込みが今回の問題の原因となっていそうです。

![bundle-analyzerの結果](/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png)

`yarn.lock` を参照すると、 `refractor` は [react\-syntax\-highlighter/react\-syntax\-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter) から読み込まれていることが分かりました。

```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"
```

これでパフォーマンス問題の原因が特定できたので、残りはこの問題を改修していきます。

## パフォーマンス改善
`reflactor` には、シンタックスハイライトで利用する言語ごとのjsファイルが含まれており、それらが初回レンダリングのタイミングで全て読み込まれることで、パフォーマンス低下を引き起こしていました。`react-syntax-highlighter` は動的インポートにも対応しているので、今回は動的インポートによりレンダリングブロックをしないように修正をします。

ただ、最終的に読み込むファイルの転送量が多いことに変わりないので、将来的には別のアプローチで解決したいです。

```typescript
// import { Prism as SyntaxHilighter } from 'react-syntax-highlighter';
import { PrismAsync as SyntaxHilighter } from 'react-syntax-highlighter';
```

動的インポートに変更した後の bundle anlyzer の結果をみると、 `refractor-import.xxx.js` として `refractor` の読み込みが新しいチャンクとして切り出されています。`[slug]-xxx.js` のファイルサイズ も 722.4kb から 216.54kb に削減されています。

![動的インポートのbundle-analyzerの結果](/images/posts/nextjs-perf-improvement/dynamic-import-bundle-analyzer-result.png)

修正後の `[slug]-xxx.js` の中身を見てみると、新たに別の問題が見えてきました。`react-syntax-highlighter`が全てのテーマファイルを読み込んでいます。

![[slug]-xxx.jsのbundle-analyzerの結果](/images/posts/nextjs-perf-improvement/bundle-analyzer-result-slug.png)

この読み込みも不要なので、必要なテーマファイルだけを読み込むように修正します。

```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';
```

最終的に `[slug]-xxx.js` のファイルサイズが 722.kb から 106.5kb と1/7のサイズ削減できました🎉
これでレンダリングブロッキングの時間が大幅に削減されるので、Ligthouseのパフォーマンス結果も改善されます。

![最終的なbundle-analyzerの結果](/images/posts/nextjs-perf-improvement/bundle-analyzer-finally.png)

## さいごに
今回は1番大きな問題を対象として改善策を実施しましたが、画像の最適化や画像の遅延ロード、その他の不要なJavaScriptファイルの削除と改善項目はまだまだ沢山あります。また、Next.jsのリプレースによって新しく導入したライブラリにより意図せずにパフォーマンス低下が起きてしまったので、今後は [GoogleChrome/lighthouse\-ci](https://github.com/GoogleChrome/lighthouse-ci) などを導入して継続的にパフォーマンスなどを計測する仕組みを用意していきたいです。


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

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


## はじめに
TypeScriptをトランスパイルする手段として、主にtscとbabelという二つの選択肢があります。それぞれのツール役割について、どのような違いがあるかをまとめました。  
（webpackを利用する場合は、ts-loaderなどもありますが）

## tsc
tscはTypeScriptの開発チームが提供しているTypeScriptのトランスパイラで、TypeScriptで書かれたソースコードをJavaScriptへとトランスパイルするツールです。tscは `tsconfig.json` の `target` オプションで古いJavaScriptへのトランスパイルをサポートしています。例えば、`"target": "es5"` と指定することで、TypeScriptのコードをIE11などでも動くJavaScriptの構文にトランスパイルしてくれます。

しかし、ここで注意する点があります。tscのトランスパイル対象となるのは **JavaScriptの構文だけ** ということです。具体例として、次の `index.ts` をトランスパイルした `index.js` のコードを見てみます。  

```typescript
// tsconfig.json
{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "ES2015"
    ]
  }
}

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

// index.js
var fetchNumber = function () {
    return new Promise(function (resolve, reject) {
        resolve(1);
    });
};
```

`() => {}` のアロー関数はES2015で導入された構文であるため、IE11では利用できません。そこで、tscがアロー関数を `function() {}` のようにES5の形式に変換してくれています。ただ、`Promise` はそのままの形式で残っています。`Promise`もES2015から導入された仕組みのため、このままでは、IE11では動かすことができません。
これは、先ほども述べたように tscのトランスパイルは **JavaScriptの構文だけ** を対象しており、Promiseなどの組み込みオブジェクトは構文でないため、tscのトランスパイル対象から外れてしまいます。

この問題を解決する方法として次に説明する Babel を利用します。

## Babel
BabelはES2020などの最新のJavaScriptコードをIE11などのブラウザでも動作するJavaScriptコードに変換するトランパイラーです。また構文のトランスパイル以外にも、テストで利用する `test-id` や デバッグ目的の `console.log` をプロダクションビルドの時だけ削除するなどのトランスパイルを実行することができます。

### Plugins と Presets
Babelを利用する上で `Plugins` と `Presets` という二つの概念だけは把握しておく必要があります。  

`Plugins`はBabelでどのようにコードを変換するかを定義したJSのプログラムです。  
例えば、`@babel/plugin-transform-arrow-functions` は ES2015から導入されたアロー関数 `() => {}` を `function() {}` というES5の形式に変化するためのプラグインです。Babelを利用する時は、複数のプラグインを組み合わせることで、目的に合わせてコードをトランスパイルしていきます。

実際にES2015の構文をES5にトランスパイルするには多くのプラグインを利用する必要があります。必要なプラグインを一つずつインストールして管理するのは大変です。一つのパッケージとして集約されていると、利用する際にパッケージをインストールするだけで良くなり非常に便利です。  

この複数のプラグインを目的に応じてパッケージとして集約する仕組みが `Presets` です。ユーザーが独自のプリセットを定義することも、他の人が定義したプリセットをインストールして利用することもできます。頻繁に利用するプリセットとしては、Babel公式が提供している `@babel/preset-env` があります。これは、ES2015以降のJavaScriptの構文をES5にトランスパイルするプラグインを集約したプリセットです。集約されているプラグインは、[babel/available\-plugins\.js at master · babel/babel](https://github.com/babel/babel/blob/master/packages/babel-preset-env/src/available-plugins.js) で確認できます。

### TypeScriptのトランスパイル
実際に先ほどのTypeScriptのコードをBabelを利用してIE11でも動作するコードに変換してみます。  

最初に必要なパッケージをインストールします。

- @babel/cli: Babelのcliツール
- @babel/core: Babelのコア機能
- @babel/preset-env: JavaScriptの構文をトランスパイルする かつ PromiseなどのPolyfillを注入
- @babel/preset-typescript: TypeScriptをトランスパイルする
- core-js@3: PromiseなどのPolyfillを定義したモジュール

```bash
# babelと関連するプリセットのインストール
$ yarn add -D @babel/cli @babel/core @babel/preset-env @babel/preset-typescript
$ yarn add core-js@3
```

Babelの設定ファイルはこんな感じです。

```json
// babel.config.json
{
  "presets": [
    [
      "@babel/preset-typescript",
      "@babel/preset-env",
      {
        "targets": {
          "ie": "11"
        },
        "useBuiltIns": "usage"
      }
    ]
  ]
}
```

TypeScript => @babel/preset-typescript => @babel/preset-env => JavaScript  
という流れでトランスパイルがされていきます。tscと異なる点は、`"useBuiltIns": "usage"`を指定することで、`targets`オプションで
指定しているブラウザでも動作させるために必要なPolyfillがBabelにより自動で注入されます。

実際に先ほどの `index.ts` に対してトランスパイルを実行して、出力されるJavaScriptを確認してみます。

```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);
  });
};
```

tscと比較して、`Promise`のPolyfillが別モジュールとして読み込まれています。このようにBabelを利用することで、より柔軟にトランスパイルすることができます。

ただし、ここでも注意が必要でPolyfillを `reuire` という CommonJS Module 形式で読み込んでいるため、このままではブラウザ上で実行することができません。そのため、このモジュール読み込みを解決するために、モジュールバンドラーのWebpackを利用します。


### @babel/preset-typescriptの注意点
@babel/preset-typescriptの利用で知っておくべき注意点がいくつかあります。

#### 型チェック
ひとつは、型チェックが実行されないことです。BabelではTypeScriptから型を剥がして、JavaScriptにトランスパイルする作業だけを実行するため、仮に型の不整合が存在しても、トランスパイルが成功してしまいます。

```typescript
// src/index.ts
const n: number = "hello";
```

上記のコードをtscとBabelで実行してみると、Babelでは型エラーが発生せずにトランスパイルが成功します。これでは、TypeScriptを使う一番の目的である型の恩恵が受けられません。

```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.
```

そのため、Babelでトランスパイルをする場合は、事前にtscで別途型チェックを実施する必要があります。

```bash
$ tsc --noEmit src/index.ts && babel src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.
```

#### 一部機能の非対応
`const enums` や デコレーターなど一部のTypeScriptの機能を正常にトランスパイルできない問題があります。対応していないと絶対に困る問題ではないですが、プロジェクトによっては重要な問題となるので、これらの存在を認識していくことが重要です。  
詳細は [Choosing between Babel and TypeScript](https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/) を参照してください。

## おわりに
Babelで
今回は @babel/preset-typescript を利用したTypeScriptのトランスパイルを通して、tscとBabelの違いをまとめました。Babelで出力されたファイルはモジュール読み込みを含むため、webpackを利用してモジュール解決をする必要があります。しかし、webpackを利用する場合に、TypeScriptをトランスパイルする方法として `ts-loader` を使う方法もあります。別の機会にここら辺の話をまとめたいです。

## 参考
- [TypeScript: TSConfig Reference \- Docs on every TSConfig option](https://www.typescriptlang.org/tsconfig#target)
- [@babel/preset\-env · Babel](https://babeljs.io/docs/en/babel-preset-env#usebuiltins)
- [TypeScript and Babel 7 \| TypeScript](https://devblogs.microsoft.com/typescript/typescript-and-babel-7/)
- [Choosing between Babel and TypeScript](https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/)
- [TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 \- Qiita](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)


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

tscとBabel

![wasm-othello](/images/posts/wasm-othello/wasm-othello.png)

この記事は [Hamee Advent Calendar 2020](https://qiita.com/advent-calendar/2020/hamee) の3日目の記事です。  

↓のURLからオセロが遊べるので、ぜひ遊んでみてください！  
[https://wasm-othello.t-yng.jp/](https://wasm-othello.t-yng.jp/)

最上位のレベル6は普通に強いです！CPUのアルゴリズムは自分の普段の思考をベースにしているので、レベル6に勝てない人はリアルで僕とオセロをやっても勝てないレベルです。(多分)

全体のソースコードは [t-yng/wasm-othello](https://github.com/t-yng/wasm-othello) に置いてあります。

実装したのは2020年3月頃とかなり前なのですが供養も兼ねて記事にまとめました。  
余談ですが、もうすぐ令和2年が終わるという事実に衝撃を受けながら、この記事を書いています。

## はじめに

ブラウザでのWebAssemblyの処理速度がJavaScriptと比較してどれだけ向上するのかを体感したく、オセロのCPUをTypeScriptとWebAssemblyで実装して速度比較をしてみました。

WebAssemblyの実装にはRustを利用しています。Rustを選択した理由は自分がRustを書きたかったのが一番の理由ですが、Rustは言語の仕組みとしてガベージコレクションを持たないため、.wasm にコンパイルしたバイナリコードを軽量化できる特徴があります。

## WebAssemblyとは？
> WebAssemblyは、ウェブブラウザのクライアントサイドスクリプトとして動作するプログラミング言語（低水準言語）である。wasmとも称されており、ブラウザ上でバイナリフォーマットの形で実行可能であることを特徴とする。
> 
> [WebAssembly - Wikipedia](https://ja.wikipedia.org/wiki/WebAssembly)

バイナリ形式で実行されるので、JavaScriptと比較してより高速な処理速度が実現できます。RustやC/C++やTypeScriptなどの言語からコンパイルできるため、WebフロントエンドのビジネスロジックをJavaScript以外の言語で記述することができるのも一つの特徴です。

## WebAssemblyを利用した動作イメージ
最善手を探索するビジネスロジック部分をRustで実装・コンパイルして .wasm 形式のバイナリコードを出力します。このファイルをJavaScriptファイルを同じ要領で配信して、ブラウザ上で読み込ます。JavaScriptからwasmのバイナリコードを呼び出すことで、一部のビジネスロジックをWebAssemblyで実行できます。

![WebAssemblyを利用したイメージ図](/images/posts/wasm-othello/wasm.png)

## ミニマックス法を用いたCPUの実装
ミニマックス法とは、オセロや将棋などのゲームアルゴリズムを実装する時に利用される事の多い探索手法の一つです。評価関数を用いて盤面の評価値を計算して、自分の手番では評価値が最大となり、相手の手番では評価値が最小となる最善手を選択するアルゴリズムです。

例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のためにAとBの2箇所に絞って探索を行い、2手先までを探索してみます。

![盤面](/images/posts/wasm-othello/board.png)

相手は常に最前手を打つと予測するので、Aを打った場合は最大評価値は100となる位置に石を置いてきます。これに対してBに打った場合は最大評価値は15の位置に石を置いてきます。ここではBに打った方が自分が有利なので、Bを最善手として決定します。

![Aに打った場合](/images/posts/wasm-othello/board_select_A.png)

![Bに打った場合](/images/posts/wasm-othello/board_select_B.png)

このアルゴリズムではよりN手先を探索する方が精度が上がり最善手の精度が高くなります。しかし、探索の深さが増えるほどに探索範囲が爆発的に増えて計算時間が膨大になるため、ある一定の深さで探索を打ち切るという事をします。逆に言えば、処理速度を向上させればそれだけ探索範囲を深くできるためCPUを強くすることができます。  

今回のオセロではCPUのレベルを探索の深さと合わせてあるため、レベルを上げるほど探索範囲が増大してCPUの計算時間が処理速度に依存するようになっています。

ミニマックス法は参考となるサイトが沢山あるので、詳細はそちらを参照してください。  
- [ミニマックス法 \- Wikipedia](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)
- [web帳 \| 5分で覚えるAI Minimax（ミニマックス）法とalpha\-beta法](https://www.webcyou.com/?p=6997)

実装したオセロのアルゴリズムでは次の評価ルールに基づいて評価関数を実装しました。

- 中盤までは相手の石が多い方が評価値を高くする
- 後半は自分の石が多い方が評価値を高くする
- 自分の石が角にある +500
- 相手の石が角にある - 500
- 自分の石が角の上下にある -30
- 相手の石が角の上下にある +30
- 自分の石が角の斜めにある -100
- 相手の石が角の斜めにある +100

## 速度結果
TypeScript実装とWebAssembly（Rust実装）での処理速度をグラフで可視化してみました。

![処理速度のグラフ](/images/posts/wasm-othello/speed.png)

盤面によっては7~8倍ぐらいの速度差が出ておりWebAssemblyの速度に驚きました。

## さいごに
オセロを実装したのは6月ぐらいだと思っていたのですが、実際は3月頃で想像以上の月日の流れの速さに驚きました。Rustで実装してみると所有権やライフタイムなど自分の知らない新しい概念が出てきて面白かったです。

Rustの所有権については、[Rustの所有権と借用を理解する](https://t-yng.jp/posts/rust-ownership/)でまとめているので、興味があったら読んでみてください。

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

WebAssemblyでオセロを作った話

神奈川の田舎で働いてるフロントエンドエンジニアのブログ