SolidJS + vite + tailwindcss な環境を作る（Storybook, vitest対応）


先日公開された State of JS 2021 を見ていて、 `SolidJS` という気になるフレームワークを見つけたので、少し齧ってみようと思いました。  
まだ情報が少ない、かつ、 テストツールや Storybook などのツールを併用するにはまだひと工夫必要だったので、その対応方法と実際に作成したテンプレートについてサクッとまとめておきます。

## SolidJS とは

[SolidJS](https://www.solidjs.com/)  
React や Vue などの Front-end フレームワークの 1 つです。

すごく雑にまとめると、 Svelte と React の融合みたいなものです...!  
昨今の Web Frontend では、 React が使われる事が多いなという感覚です。  
SolidJS は、 React の宣言的な書き味を持ちつつ、 Svelte のように実 DOM を操作するパフォーマンス性を兼ね備えています。

```tsx
import { createSignal, onCleanup } from 'solid-js'
import { render } from 'solid-js/web'

const CountingComponent = () => {
  const [count, setCount] = createSignal(0)
  const interval = setInterval(() => setCount(count => count + 1), 1000)
  onCleanup(() => clearInterval(interval))
  return <div>Count value is {count()}</div>
}

render(() => <CountingComponent />, document.getElementById('app'))
```

React から入った自分は、 Svelte の書き味に慣れず... SolidJS が v1 として公開されたタイミングで、シンプルに「良さそう...!」と思いました。  
（どのフレームワークも思想がしっかりしていて、選択肢が増えたという気持ちです）

## どんな構成を作ったか

今回作成したテンプレートは、以下の構成で作成しました。  
開発体験として実用的な環境を構築できそうかという観点で作成しています。

- SolidJS
- TypeScript
- tailwindcss
- vite
- vitest
- ESlint
- Prettier
- Storybook
- pnpm

決してイケイケだからという理由ではありません...!  
自分のキャッチアップも兼ねています。本当です。

作成したテンプレートの完成形はこちら [starter-for-solid](https://github.com/hey3/starter-for-solid) です。

## 環境を作っていく

1 から環境を作っていきます。  
この辺は公式ドキュメントを見ながらでスイスイでした。  
パッケージマネージャーには [pnpm](https://pnpm.io/) を使っています。適宜 `npm` や `yarn` に読み替えてください。

### package.json を用意する

まずはここから。  
環境を用意するディレクトリで、以下のコマンドを実行。

```shell
$ pnpm init
```

結果

```shell
.
`-- package.json
```

### SolidJS 実行に最低限必要なものを入れる

まずは SolidJS を実行できる環境を用意します。  
以下のコマンドで install します。

```shell
$ pnpm add solid-js
$ pnpm add -D typescript vite vite-plugin-solid
```

今回 TypeScript を使うため、 `tsconfig.json` を作成します。

```shell
$ pnpm tsc --init
```

以下に書き換える。  
適宜好きなオプションに書き換えてください。

```json
// tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "target": "es5",
    "module": "ESNext",
    "lib": ["ESNext", "DOM", "DOM.Iterable"],
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "preserve", // ここ大事
    "jsxImportSource": "solid-js", // ここ大事
    "moduleResolution": "node",
    "newLine": "lf",
    "noEmit": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "types": ["vite/client"],
    "skipLibCheck": true,
    "strict": true
  },
  "include": ["**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}
```

vite で SolidJS を扱えるようにします。

```ts
// vite.config.ts

import { defineConfig } from 'vite'
import solidPlugin from 'vite-plugin-solid'

export default defineConfig({
  plugins: [solidPlugin()],
})
```

プロジェクトルートに `index.html` を作成します。

```html
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <link rel="shortcut icon" type="image/ico" href="/src/assets/favicon.ico" />
    <title>Solid App</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>

    <script src="/src/index.tsx" type="module"></script>
  </body>
</html>
```

`/src/index.tsx` にコンポーネントを作成します。  
（React の感覚のまま `jsx` が使えるの、良い...!）

```tsx
// ./src/index.tsx

import { createSignal, onCleanup } from 'solid-js'
import { render } from 'solid-js/web'

const CountingComponent = () => {
  const [count, setCount] = createSignal(0)
  const interval = setInterval(() => setCount(count => count + 1), 1000)
  onCleanup(() => clearInterval(interval))
  return <div>Count value is {count()}</div>
}

render(() => <CountingComponent />, document.getElementById('root'))
```

`package.json` の `scripts` に実行コマンドを追加して実行してみる。

```json
// package.json

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}
```

```shell
$ pnpm dev
```

`localhost:3000` にアクセスすると、表示ができていることが確認できるかと思います。  
基本的にはこれだけです。次に tailwindcss の設定をしていきます。

### tailwindcss を使えるようにする

必要なものは以下です。インストールしていきましょう！

```shell
$ pnpm add -D tailwindcss postcss autoprefixer
```

次に `tailwind.config.js` と `postcss.config.js` を作成します。

```js
// tailwind.config.js

module.exports = {
  content: ['./index.html', './src/**/*.{js,ts,jsx,tsx}'],
  darkMode: 'media',
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

// postcss.config.json

module.exports = {
  plugins: [require('tailwindcss'), require('autoprefixer')],
}
```

後は `/src/index.css` と、それを App で読み込ませれば OK です。  
試しに文字色を赤にして反映されているか確認してみます。

```css
// ./src/index.css

@tailwind base;
@tailwind components;
@tailwind utilities;
```

```tsx
// ./src/index.tsx

import { createSignal, onCleanup } from 'solid-js'
import { render } from 'solid-js/web'
import './index.css'

const CountingComponent = () => {
  const [count, setCount] = createSignal(0)
  const interval = setInterval(() => setCount(count => count + 1), 1000)
  onCleanup(() => clearInterval(interval))
  return <div class="text-red-500">Count value is {count()}</div>
}

render(() => <CountingComponent />, document.getElementById('root'))
```

文字色が変わっていれば OK です。

ここからは、開発時によく使うエコシステムとの連携をしていきます。

## RSLint, prettier を追加する

この辺りも難しくはありません。  
SolidJS も `jsx` を扱えるので、 React 同様の設定でいけます。

SolidJS 用の `eslint-plugin-solid` を追加するくらいの差分です。

必要なものをインストールします。  
適宜ルールの追加や設定を行ってください。  
※本テンプレートでは `eslint-plugin-jsx-a11y` と `eslint-plugin-import` を追加しています。

```shell
$ pnpm add -D eslint eslint-plugin-solid eslint-config-prettier prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser
```

`.eslintrc.js` と `.prettierrc` を作成します。

```js
// .eslintrc.js

module.exports = {
  root: true,
  env: {
    node: true,
    es2022: true,
  },
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  ignorePatterns: ['node_modules/*'],
  extends: ['eslint:recommended'],
  overrides: [
    {
      files: ['**/*.ts', '**/*.tsx'],
      parser: '@typescript-eslint/parser',
      env: {
        browser: true,
      },
      extends: [
        'plugin:@typescript-eslint/recommended',
        'plugin:solid/typescript',
        'eslint-config-prettier',
      ],
    },
  ],
}
```

```json
// .prettierrc

{
  "arrowParens": "avoid",
  "semi": false,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2
}
```

`package.json` の `scripts` にコマンドを追加しておきます。

```json
// package.json

{
  "scripts": {
    "format": "prettier --check './src/**/*.{ts,tsx,json}'",
    "format:fix": "prettier --write './src/**/*.{ts,tsx,json}'",
    "lint": "eslint './src/**/*.{ts,tsx}'",
    "lint:fix": "eslint --fix './src/**/*.{ts,tsx}'"
  }
}
```

`pnpm lint` と `pnpm format` コマンドを実行してみると、上手く効くと思います。

余談ですが、 ESLint の `plugins` と `extends` は以下のことを行っています。

- plugins  
  ルールの追加
- extends  
  ルールの設定、その他

[eslint-plugin-solid](https://github.com/joshwilsonvu/eslint-plugin-solid) の README を見てみると、 `"plugins": ["solid"]` の記述がありますが、 `plugin:solid/recommended` 及び `plugin:solid/typescript` の中で `plugins: ["solid"]` の設定もしてくれているので、プロジェクトの `.eslintrc.js` 側では省略可能です。  
FYI: [https://github.com/joshwilsonvu/eslint-plugin-solid/blob/main/src/index.ts#L33-L90](https://github.com/joshwilsonvu/eslint-plugin-solid/blob/main/src/index.ts#L33-L90)  
把握していると捗ります!!

## 躓いたポイント

後は Storybook とテスト環境を用意するだけなのですが、この辺りで少し躓いたのでその備忘録を記載しておきます。

### Storybook

SoliJS のコンポーネントを Storybook でデバッグするための設定をしている時に躓きました。。  
結論としては、babel preset に `babel-preset-solid` を使うことで解決できました。  
また、 tailwindcss も使えるように `@storybook/addon-postcss` を追加する必要があります。

Storybook デフォルトでは、トランスパイルに Babel が使われます。  
つまり、 SolidJS 構文を Babel がトランスパイル可能な設定を行えば良いことになります。

本テンプレートはデフォルト設定のまま、 webpack4 による build 、 babel によるトランスパイルとしています。（2022/03 時点）  
将来的には Storybook の builder を vite に統一しようと思っています...!

まずは必要なライブラリをインストールします。  
適宜アドオンの追加や設定を行ってください。  
※本テンプレートでは `@storybook/addon-a11y` を追加しています。

```shell
$ pnpm add -D @storybook/html @storybook/addon-essentials @storybook/addon-postcss babel-preset-solid @babel/preset-typescript
```

`.storybook` ディレクトリに `main.js` と `preview.js` を作成します。

```js
// ./.storybook/main.js

module.exports = {
  stories: ['../src'],
  addons: [
    '@storybook/addon-essentials',
    {
      name: '@storybook/addon-postcss',
      options: {
        postcssLoaderOptions: {
          implementation: require('postcss'),
        },
      },
    },
  ],
  // babelrc でも良いですが、他に babel config を流用している箇所が無いため、Storybook の設定に書いています。
  babel: async options => ({
    ...options,
    presets: ['solid', '@babel/preset-typescript'],
  }),
}

// ./.storybook/preview.js

import '../src/index.css' // tailwindcss 用
```

`package.json` の `scripts` にコマンドを追加しておきます。

```json
// package.json

{
  "scripts": {
    "storybook": "start-storybook -p 6006"
  }
}
```

`src` ディレクトリ以下に、何かしら `*.stories.tsx` を用意して `pnpm storybook` コマンドを実行してみると、 Storybook で SolidJS のコンポーネントが確認できると思います。

### テストツール

テストが書けることは必須です。  
本テンプレートにもテストを書ける基盤を用意しました。

躓いた点は、 jest を使おうとしていて、その設定が上手く出来ませんでした。。  
これは圧倒的に jest 力が足りませんでした。

まず最初に SolidJS でテストを書きたいと思ったときに、普段使っている jest を選びました。  
公式にも [solid-jest](https://github.com/solidjs/solid-jest) というライブラリが用意されており、これを使えばいけそうと安直に考えていました。  
結果、うまくいかず...ｸﾞﾇﾇ

発送を切り替え、 vite によるビルド設定を行っているので、そのまま vitest を使えないかと思いました。  
そしたら意外とすんなりいけたので、その設定を記載しておきます。

まずは必要なライブラリをインストールします。

```shell
$ pnpm add -D vitest jsdom
```

`tsconfig.json` の `types` に `vitest/global` を設定します。

```json
// tsconfig.json

{
  "types": ["vite/client", "vitest/globals"]
}
```

`vite.config.ts` に以下のように変更します。

```ts
// vite.config.ts

import { defineConfig } from 'vite'
import solidPlugin from 'vite-plugin-solid'

export default defineConfig({
  plugins: [solidPlugin()],
  // ここ以下を追加
  test: {
    environment: 'jsdom',
    transformMode: {
      web: [/\.[jt]sx?$/],
    },
    deps: {
      inline: [/solid-js/],
    },
  },
  resolve: {
    conditions: ['development', 'browser'],
  },
})
```

`package.json` の `scripts` にコマンドを追加しておきます。

```json
// package.json

{
  "scripts": {
    "test": "vitest --passWithNoTests" // test ファイルが無いときにエラーにしないオプションを付けています
  }
}
```

これで vitest を使って SolidJS のテストを書くことが出来ます。

ここまでで SolidJS を触る準備が整いました！  
自分もこれから触っていきます...!

## まとめ

今回は SolidJS の v1 公開を知って、 SolidJS を触るためのテンプレートを作成する手順を記載しました。

まだガッツリ触ったわけでは無いので、設定不備が見つかる可能性はあります。ご了承ください :pray:  
SolidJS は SSR も行うことが可能です。  
今回は React チックに CSR の SPA の用途を想定しているため、 SSR したい場合は設定がいくつか異なります。

今回作成したテンプレートも都度アップデートを行っていく予定です。  
知見のある方いましたら issue や DM でご教示頂けると嬉しいです！

作成したテンプレート：[https://github.com/hey3/starter-for-solid](https://github.com/hey3/starter-for-solid)


AWS CDK で lambda のバージョンが上手く発行できない時の対処


AWS CDK を使っていて、 lambda のバージョン発行しているのに「バージョンが上手く発行されない！」、「古いバージョンが残らない！」となって結構困っていた時期がありました。  
本記事は、その問題の解決方法を簡単に記述していきます。

## 検証環境

- aws-cdk: 1.86.0
- @aws-cdk/aws-lambda: 1.86.0
- typescript: 4.1.3
- lambda runtime: Node.js 12

本記事では

```shell
$ cdk init app --language typescript
```

で作成したものをベースに説明していきます。

サンプルコードは[こちら](https://github.com/hey3/aws-cdk-lambda-version-sample)  
サンプルコードは多少使いやすいように config をいじっています。

## 上手く行かない実装

最小限のコードで説明していきます。

最初はドキュメントもあまり読まずに、「Version 生成すれば良いだろう」という気持ちで `Version` class のインスタンスを作れば出来るんじゃと思い、以下のような記述をしていました。

※ lambda 関数は `functions` ディレクトリに用意しています。

```ts
export class TestCdkStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    const functionName = 'MyFunction'

    const fn = new lambda.Function(this, functionName, {
      functionName,
      runtime: lambda.Runtime.NODEJS_12_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('functions/hoge'),
    })

    new lambda.Version(this, `${functionName}-Version`, {
      lambda: fn,
    })
  }
}
```

これでデプロイしてみると、 version 自体は発行されるのですが、
lambda 関数を編集してから再度デプロイしてみると新しいバージョンが発行されません。  
しかも、作成されているバージョンのコードは初期のコードのままです。（LATEST だけ更新されている状態）

これは metadata を見るとわかるのですが、どんなに lambda 関数のコードを修正したとしても作成されるバージョンのリソースは変わらないからです。

## 解決方法

上で書いた原因を基に考えると、

- デプロイ毎に新しいバージョンを作成するようにする
- 古いバージョンが削除されないようにする

を満たせば解決できそうに見えます。

### id をユニークにする

new Version の第２引数の `id` を毎回関数毎にユニークにしてあげることで、デプロイの度に新しいバージョンを作成することが出来ます。

先程のコードを以下のように修正します。

```ts
export class TestCdkStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    const functionName = 'MyFunction'

    const fn = new lambda.Function(this, functionName, {
      functionName,
      runtime: lambda.Runtime.NODEJS_12_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('functions/hoge'),
    })

    const uniqueVersionId = `${new Date().getTime()}`

    new lambda.Version(this, `${functionName}-${uniqueVersionId}`, {
      lambda: fn,
    })
  }
}
```

デプロイの時刻を各 lambda 関数バージョンの id に付与しています。

これをデプロイすると、いつも通り LATEST が更新され、新しいバージョン `2` が作成され、最新のコードがバージョン `2` として作成されます。

バージョンの更新はされましたが、過去に作成したバージョン `1` が消えてしまっているため、バージョンとしては使えないです。

ここまでは、ググると出てくるのであっさり来られるのですが、「過去のバージョン消えたら使えないな」となり結局諦めてしまっていました。

### removalPolicy を RETAIN にする

過去のバージョンが削除されてしまうのであれば、バージョンの `removalPolicy` を `RETAIN` にしてあげれば解決できそうです。  
（この組み合わせに気づくのに時間がかかりました。。。片方だけやってみてもだめ）

先程のコードを以下のように修正します。

```ts
export class TestCdkStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    const functionName = 'MyFunction'

    const fn = new lambda.Function(this, functionName, {
      functionName,
      runtime: lambda.Runtime.NODEJS_12_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('functions/hoge'),
    })

    const uniqueVersionId = `${new Date().getTime()}`

    new lambda.Version(this, `${functionName}-${uniqueVersionId}`, {
      lambda: fn,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    })
  }
}
```

`removalPolicy` を `RETAIN` にすると、そのリソースの `UpdateReplacePolicy` と `DeletionPolicy` に `Retain` が設定されます。

lambda 関数更新後にデプロイしてみると、以降作成されたバージョンはスタックの更新・削除をしても保持してくれるようになります。  
※注意としては `RETAIN` に設定する前のバージョン（ここでは `2` ）は removalPolicy が `Retain` ではないので削除されます。

なので `RETAIN` が残ることを確認するために２回デプロイを行います。

結果としては、  
１度目のデプロイ -> LATEST と同じコードのバージョン `3` のみが残る  
２度目のデプロイ -> １度目のコードのバージョン `3` と LATEST と同じコードのバージョン `4` が残る  
となります。

これでバージョンを管理することが出来るようになりました。

### コード差分が無い時のエラー対応をする

ここまでで、 `removalPolicy` を `RETAIN` にした場合に起こるエラーがあります。  
それは、 lambda 関数のコードを更新せずにデプロイを行った場合です。

コード差分が無いのに新しいバージョンを発行しようとすると

```
A version for this Lambda function exists ( )
```

のようなエラーが発生します。  
これは lambda の仕様によるものです。

これを回避するためのハックが存在します。（そもそも差分がなければバージョン発行しない方が理想だとは思います）

lambda の description に対しても `uniqueVersionId` を含めることで差分を発生させます。

```ts
export class TestCdkStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    const functionName = 'MyFunction'

    const uniqueVersionId = `${new Date().getTime()}`

    const fn = new lambda.Function(this, functionName, {
      functionName,
      description: `This lambda deployed at ${uniqueVersionId}`, // ここを追加
      runtime: lambda.Runtime.NODEJS_12_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('functions/hoge'),
    })

    new lambda.Version(this, `${functionName}-${uniqueVersionId}`, {
      lambda: fn,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    })
  }
}
```

## Alias を設定する場合

dev や prod 環境毎に lambda 関数の指定のバージョンに Alias を設定したくなると思います。

その場合には、

- dev は最新のバージョンに対して Alias を設定
- prod は指定のバージョン固定にし、アップデートしたい場合に最新のバージョンに合わせる

dev の例

```ts
const version = new lambda.Version(this, `${functionName}-${uniqueVersionId}`, {
  lambda: fn,
  removalPolicy: cdk.RemovalPolicy.RETAIN,
})

new lambda.Alias(this, 'Dev-Alias', {
  aliasName: 'dev',
  version,
})
```

prod の例

```ts
new lambda.Alias(this, 'Prod-Alias', {
  aliasName: 'prod',
  version: lambda.Version.fromVersionArn(this, 'Prod-Version', `${fn.functionArn}:3`),
})
```

などとすると良いと思います。  
prod のバージョン指定部分などの運用は色んなやり方があると思うので今回は割愛します。

## まとめ

今回は、 AWS CDK で lambda 関数のバージョン管理をする時に少し躓いていたので根本から理解して解決しました。  
気づくと簡単ですが気づくまで大変でした。。

重要なのは

- デプロイ毎に新しいバージョンを作成するようにする
- 古いバージョンが削除されないようにする

です。

snapshot test ではちょっと不便さが出るかも。


Next.js の zero-config の恩恵を受けて SPA を作る


Next.js の zero-config の恩恵を受けながら SPA だけのアプリケーション作成できないかなと試行錯誤し、あーこれでいけるんだとなった備忘録です。  
SSG や SSR を使わなければ Cloudfront + S3 のような構成で静的サイトホスティングも出来るので、サクッと開発したい時に便利だなと思いました。

## TL;DR

- Static HTML Export を使って静的 HTML を吐き出す
- ルーティングライブラリを使って `pages/index.js` 内でルーティングを行えるようにする
- サーバー側での pre-render を抑制する

## なぜ Next.js を使うのか

Dynamic import を使うことでバンドルを分割でき、これにより、大規模な SPA に関連するパフォーマンスの問題の１つを解決できるためです。  
また、これが zero-config によって複雑な設定をしなくて済むのがでかいです。

API Routes や SSG, SSR などの機能もありますが、今回は単純な Web サーバの上で SPA を動かすことを考えます。

## ルーティングライブラリを使って SPA にする

まずはルーティングに必要なライブラリを追加します。

```shell
$ yarn add react-router-dom
```

React router を使用する理由は、全てのネストされたルートをフラット化するためです。

※ `react-router` と `react-router-dom` の違いについて  
`react-router` は React router のコアであり、ブラウザで使用するために wrap したものが `react-router-dom` です。  
`BrowserRouter`, `HashRouter`, `Link`, `LinkNav` コンポーネントが `react-router` を wrap した形で追加で実装されています。  
[FYI: react-router/packages/react-router-dom/modules](https://github.com/ReactTraining/react-router/tree/master/packages/react-router-dom/modules)

## サーバー側での pre-render を抑制する

React Router を入れた状態で `pages/index.js` を以下のように修正してみます。

```jsx
// pages/index.js
import { BrowserRouter as Router, Switch, Route, Link } from 'react-router-dom'

export default function App() {
  return (
    <Router>
      <div>
        <ul>
          <li>
            <Link to="/">Home</Link>
          </li>
          <li>
            <Link to="/hoge">Hoge Page</Link>
          </li>
        </ul>

        <Switch>
          <Route path="/hoge">
            <h2>This is hoge page.</h2>
          </Route>
          <Route path="/">
            <h2>This is Home page</h2>
          </Route>
        </Switch>
      </div>
    </Router>
  )
}
```

これで `yarn dev` を実行してページを開いてみると以下のエラーが吐き出されます。

`Error: Invariant failed: Browser history needs a DOM`

これは、Next.js が開発モードで開発サーバー上のページを事前にレンダリングしようとするために発生します。  
React Router は、ブラウザによって提供されるグローバルの `windows` オブジェクトへのアクセスを必要とします。しかし、サーバー環境では `windows` は利用不可であるため、このようなエラーが吐き出されます。

これを解決するために `_app.js` でサーバーでの pre-render を抑制します。

```jsx
// _pages/_app.js

const App = ({ Component, pageProps }) => {
  return <div>{typeof window === 'undefined' ? null : <Component {...pageProps} />}</div>
}

export default App
```

サーバー側では `null` を返す事でレンダリングを行わないようにします。これで先程のエラーは解消することができます。  
ただ、サーバーのレンダリング結果とクライアントのレンダリング結果が異なることになるため、コンソール上に以下のようなエラーが表示されます。

`Expected server HTML to contain a matching <div> in <div>.`

流れは以下のようになっています。

1. サーバー上で pre-render が行われる
2. pre-render 結果をブラウザに返信
3. ブラウザで re-hydrate が行われる

re-hydrate 時にはブラウザでレンダリングが行われた結果がサーバーでレンダリングされたバージョンと同じかを比較しています。  
一致しない場合に React が上記エラーを吐き出します。

このエラーを抑制するために `suppressHydrationWarning` というものが React に用意されています。

> If you use server-side React rendering, normally there is a warning when the server and the client render different content. However, in some rare cases, it is very hard or impossible to guarantee an exact match. For example, timestamps are expected to differ on the server and on the client.

[引用 - React DOM Elements#suppressHydrationWarning](https://reactjs.org/docs/dom-elements.html#suppresshydrationwarning)

意図的にサーバー側で `null` を返しているため、今回は `suppressHydrationWarning` を使う事でこの警告を無視します。

`pages/_app.js` を以下のように変更します。

```jsx
// _pages/_app.js

const App = ({ Component, pageProps }) => {
  return (
    // この div で suppressHydrationWarning を true に設定
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  )
}

export default App
```

ここまでで一旦アプリを動かせる状態になります。

## rewrites で全てのパスを pages/index.js にリダイレクトする

このままだと、 React Router と Next Router が相互作用してしまいます。

試しに `/about` ページを表示後にリロードを行うと `404 Not Found` になります。  
これは、ページが再読込されることで Next.js は `pages/about` を読み込もうとします。 `pages/about.js` は実装していないため、 Not Found になるというわけです。

この問題を解決するには `next.config.js` で [rewrites](https://nextjs.org/docs/api-reference/next.config.js/rewrites) を記述することで解決できます。  
※ `rewrites` は Next.js v9.5 以上が必要です。

`rewrites` は指定のソース URL を宛先 URL にマッピングすることが可能になります。

ルートディレクトリに `next.config.js` ファイルを用意し、以下の記述を加えます。

```js
// next.config.js
module.exports = {
  async rewrites() {
    return [
      {
        source: '/:any*',
        destination: '/',
      },
    ]
  },
}
```

`rewrites` の各プロパティには、 Path Matching, Wildcard, Regex の使用が可能です。  
上記のように記述することで、全てのルートを `pages/index.js` にマップする事が出来ます。

`next.config.js` を作成後、再度 `/about` ページを表示してリロードを行ってみると、正常に `/about` ページが表示されることが確認できます。

`rewrites` はソース URL に該当するファイルが存在する場合、このルールを無視します。  
なので、この状態で、 `pages/about.js` を実装すると、 `/about` へ遷移した際には `pages/about` が読み込まれます。（すごい！）

また、 Next.js の利点の１つである SSR, SSG をページ単位で選択できることにも対応しています。  
上記の `rewrites` の設定で、後に SSR のページを追加した場合、そのページは SSR でレンダリングされたページとして動作します。（※このページへのリンクは `next/link` の `Link` コンポーネントを使用する必要があります。）

### deploy 先では別途リダイレクトルールの設定が必要

後は、 Static HTML Export によって吐き出された静的ファイルを Web サーバーに deploy すれば OK です。  
しかし、Static HTML Export 時には `rewrites` は適用されません。  
[FYI - next export No Custom Routes](https://github.com/vercel/next.js/blob/master/errors/export-no-custom-routes.md)

そのため、 deploy 先に設定によってはリダイレクトルールを設定する必要が出てきます。  
今回は AWS 環境に deploy する場合の手順を例として記載しておきます。構成は cloudfront + s3 での単純な構成で行います。

1. S3 にバケットを作成
2. 作成したバケットに静的ファイルをアップロード  
   `next build` -> `next export` -> `aws s3 sync ./out s3://{bucketName}`
3. バケットプロパティで静的ウェブサイトホスティングを有効にする  
   インデックスドキュメント、エラードキュメントを `index.html` に設定
4. 作成した s3 バケットを Origin とする cloudfront distribution を作成  
   Restric Bucket Access を Yes  
   OAI を作成  
   Grant Read Permissions on Bucket を Yes(バケットポリシーを更新してくれる)
5. cloudfront にカスタムエラーレスポンスを設定  
   index.html 以外のファイルパスは 403 になるため、HTTP Error Code: 403、 Response Page Path: / として設定

こうすることで aws で Next.js で作成した SPA を動かすことが出来ます。

## まとめ

Next.js は凄く便利で、SPA も Next.js の恩恵を受けながら開発したいと思っていましたが、簡単な設定をするだけで使うことが出来ました。  
よくあるブラウザのストレージにトークンを保存してルーティングを制御するなども問題なく出来ました。

サンプルで作成したソースコードは [こちら](https://github.com/hey3/nextjs-spa-sample) です。

Static HTML Export を使用する際には他にも注意しておく事柄があります。  
[Static HTML Export#caveats](https://nextjs.org/docs/advanced-features/static-html-export#caveats) に目を通しておくと良いと思います。


dotenv-webpack と DefinePlugin の関係を理解してみた


webpack で bundle する際の環境変数の扱いに対して曖昧な知識だったので、よく使っていた dotenv-webpack, DefinePlugin それぞれの動きを確認してみました。  
自分用の React + typescript テンプレートを作成した際にも混乱した使い方をしてしまっていたので、その時の反省も含んでいます。

## 検証環境

- webpack: 4.44.2
- webpack-cli: 4.3.1
- dotenv-webpack: 6.0.0

## dotenv-webpack とは

> A secure webpack plugin that supports dotenv and other environment variables and only exposes what you choose and use.

[引用 - mrsteele/dotenv-webpack](https://github.com/mrsteele/dotenv-webpack)

`dotenv-webpack` は [dotenv](https://github.com/motdotla/dotenv) と [webpack.DefinePlugin](https://github.com/webpack/webpack/blob/master/lib/DefinePlugin.js) を wrap したものです。
`dotenv-webpack` は指定の `.env` ファイルに記述した環境変数を `process.env.***` に設定し、コード上で使用されている場合に webpack の bundle 時に置き換えてくれます。

```js
// .env
MESSAGE = 'hello'

// webpack.config.js
const Dotenv = require('dotenv-webpack')

module.exports = {
  // ...
  plugins: [new Dotenv()],
}

// script
console.log(process.env.MESSAGE)

// result
console.log('hello')
```

## DefinePlugin とは

> The DefinePlugin allows you to create global constants which can be configured at compile time.

[引用 - webpack/DefinePlugin](https://webpack.js.org/plugins/define-plugin/)

`DefinePlugin` は webpack 本体のプラグインです。  
`DefinePlugin` はコンパイル時に構成できるグローバル定数を作成することが出来ます。  
詳細は後に記載しますが、 `dotenv-webpack` もこの `DefinePlugin` を用いて定数の設定を行っています。

```js
// webpack.config.js
const webpack = require('webpack')

module.exports = {
  // ...
  plugins: [
    new webpack.DefinePlugin({
      MESSAGE: JSON.stringify('hello'),
    }),
  ],
}

// script
console.log(MESSAGE)

// result
console.log('hello')
```

## それぞれの動作を実際に確認してみる

それぞれ簡潔に使い方はわかりましたが、実際どんな挙動をしているのかコードを基に見ていきます。

### dotenv-webpack

dotenv-webpack のコードを見てみます。（一部抜粋）

[FYI: dotenv-webpack/src/index.js#L19-L176](https://github.com/mrsteele/dotenv-webpack/blob/master/src/index.js#L19-L176)

```js
class Dotenv {
  constructor(config = {}) {
    this.config = Object.assign(
      {},
      {
        path: './.env',
      },
      config
    )

    this.checkDeprecation()

    return new DefinePlugin(this.formatData(this.gatherVariables()))
  }

  // ...
}
```

簡単に言うと、

1. path(デフォルトは `./.env`) のファイルから環境変数を取得
2. 取得した環境変数の key を `process.env.${key}` を key とする object に整形
3. 整形された object を `DefinePlugin` に渡す

となっています。

#### dotenv-webpack の動作を確認してみる

簡単な検証環境を用意して実際に確認してみます。

構成はこんな感じです。

```
$ tree
.
├── node_modules
├── package.json
├── src
│       └── index.js
├── .env
├── webpack.config.js
└── yarn.lock
```

以下のような .env を用意します。

```js
// .env
DOTENV = 'This is dotenv-webpack variable.'
```

`webpack.config.js` は以下のようにします。

```js
// webpack.config.js
const path = require('path')
const Dotenv = require('dotenv-webpack')

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'bundle.js',
  },
  plugins: [new Dotenv()],
}
```

`src/index.js` は以下のように環境変数のログを吐くだけのコードにしています。

```js
console.log(process.env.DOTENV)
```

吐き出された `dist/bundle.js` の当該箇所は

```js
function(e,t){console.log("This is dotenv-webpack variable.")}
```

のようになります。  
`process.env.DOTENV` が .env に指定した文字列に置き換わっていることがわかります。

#### dotenv-webpack は process.env の destructuring が出来ない

ここで `dotenv-webpack` のコードを見返してみます。

[FYI: dotenv-webpack/src/index.js#L124-L151](https://github.com/mrsteele/dotenv-webpack/blob/master/src/index.js#L124-L151)

```js
formatData (vars = {}) {
const { expand } = this.config
const formatted = Object.keys(vars).reduce((obj, key) => {
  const v = vars[key]
  const vKey = `process.env.${key}`
  let vValue
  if (expand) {
    if (v.substring(0, 2) === '\\$') {
      vValue = v.substring(1)
    } else if (v.indexOf('\\$') > 0) {
      vValue = v.replace(/\\\$/g, '$')
    } else {
      vValue = interpolate(v, vars)
    }
  } else {
    vValue = v
  }

  obj[vKey] = JSON.stringify(vValue)

  return obj
}, {})

// fix in case of missing
formatted['process.env'] = '{}'

return formatted
}
```

このコードは

> 2. 取得した環境変数の key を process.env.${key} を key とする object に整形

の部分です。  
察する人は既にわかると思いますが、各環境変数をそれぞれ `process.env.***` に割り当てています。  
こうなると実際に `DefinePlugin` に渡される object は

```js
new webpack.DefinePlugin({
  'process.env.hoge': '"hoge"',
  'process.env.fuga': '"fuga"',
  'process.env': {},
})
```

のようになります。（執筆時点）

`process.env` の property に持っているわけでは無いので

```js
const { HOGE, FUGA } = process.env
```

のようなコードを書くと `undefined` になります。

結果 `dist/bundle.js` のコードは以下のようになります。

```js
const{HOGE:n,FUGA:r}={};console.log(n),console.log(r)}
```

#### destructuring するなら dotenv を使う

どうしても destructuring したい場合は `dotenv` を使って自分で `process.env` 以下に環境変数を作成することで可能になります。

```js
// .env
DOTENV = 'This is dotenv-webpack variable.'
HOGE = 'hoge'
FUGA = 'fuga'

// webpack.config.js
const path = require('path')
const webpack = require('webpack')
const dotenv = require('dotenv')

const env = dotenv.config().parsed

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'bundle.js',
  },
  plugins: [
    new webpack.DefinePlugin({
      'process.env': JSON.stringify(env),
    }),
  ],
}

// index.js
const { HOGE, FUGA } = process.env
console.log(HOGE)
console.log(FUGA)
```

こうすることで destructuring で環境変数を扱うことが出来ます。  
しかし、**実際のコードで使っていない環境変数も bundle に含まれてしまうので注意は必要です。**

bundle.js の結果

```js
function(e,t){const{HOGE:n,FUGA:r}={DOTENV:"This is dotenv-webpack variable.",HOGE:"hoge",FUGA:"fuga"};console.log(n),console.log(r)}
```

destructuring は出来ますが、 `src/index.js` で使っていない `process.env.DOTENV` の値が意図せず漏れてしまいます。  
`dotenv-webpack` が secure と標榜しているのはこの辺りになります。

### DefinePlugin

コード量が多いので抜粋して引用します。

[FYI: webpack/lib/DefinePlugin.js](https://github.com/webpack/webpack/blob/master/lib/DefinePlugin.js)

```js
const toCode = (code, parser) => {
  if (code === null) {
    return 'null'
  }
  if (code === undefined) {
    return 'undefined'
  }
  if (code instanceof RuntimeValue) {
    return toCode(code.exec(parser), parser)
  }
  if (code instanceof RegExp && code.toString) {
    return code.toString()
  }
  if (typeof code === 'function' && code.toString) {
    return '(' + code.toString() + ')'
  }
  if (typeof code === 'object') {
    return stringifyObj(code, parser)
  }
  return code + ''
}

class DefinePlugin {
  constructor(definitions) {
    this.definitions = definitions
  }
  // ...
  apply(compiler) {
    const definitions = this.definitions
    compiler.hooks.compilation.tap('DefinePlugin', (compilation, { normalModuleFactory }) => {
      // ...
      const handler = parser => {
        const walkDefinitions = (definitions, prefix) => {
          Object.keys(definitions).forEach(key => {
            const code = definitions[key]
            if (
              code &&
              typeof code === 'object' &&
              !(code instanceof RuntimeValue) &&
              !(code instanceof RegExp)
            ) {
              walkDefinitions(code, prefix + key + '.')
              applyObjectDefine(prefix + key, code)
              return
            }
            applyDefineKey(prefix, key)
            applyDefine(prefix + key, code)
          })
        }
        const applyDefineKey = (prefix, key) => {
          const splittedKey = key.split('.')
          splittedKey.slice(1).forEach((_, i) => {
            const fullKey = prefix + splittedKey.slice(0, i + 1).join('.')
            parser.hooks.canRename.for(fullKey).tap('DefinePlugin', approve)
          })
        }
      }
      const applyDefine = (key, code) => {
        const isTypeof = /^typeof\s+/.test(key)
        if (isTypeof) key = key.replace(/^typeof\s+/, '')
        let recurse = false
        let recurseTypeof = false
        if (!isTypeof) {
          parser.hooks.canRename.for(key).tap('DefinePlugin', ParserHelpers.approve)
          parser.hooks.evaluateIdentifier.for(key).tap('DefinePlugin', expr => {
            if (recurse) return
            recurse = true
            const res = parser.evaluate(toCode(code, parser))
            recurse = false
            res.setRange(expr.range)
            return res
          })
          parser.hooks.expression.for(key).tap('DefinePlugin', expr => {
            const strCode = toCode(code, parser)
            if (/__webpack_require__/.test(strCode)) {
              return ParserHelpers.toConstantDependencyWithWebpackRequire(parser, strCode)(expr)
            } else {
              return ParserHelpers.toConstantDependency(parser, strCode)(expr)
            }
          })
        }
        // ...
      }
    })
  }
  // ...
}
```

要するに、 `DefinePlugin` に渡された object の key に対して、コード上のその key を当該 property に置き換える処理をしています。

#### DefinePlugin の動作を確認してみる

`dotenv-webpack` 同様に簡単な検証環境を用意して確認してみます。

構成はこんな感じです。

```
$ tree
.
├── node_modules
├── package.json
├── src
│       └── index.js
├── webpack.config.js
└── yarn.lock
```

今回は .env を読み込まないので以下のような `webpack.config.js` にします。

```js
const path = require('path')
const webpack = require('webpack')

const definePlugin = new webpack.DefinePlugin({
  DEFINE: JSON.stringify('This is DefinePlugin variable.'),
})

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'bundle.js',
  },
  plugins: [definePlugin],
}
```

`src/index.js` は同様に定数のログを吐くだけのコードにしています。

```js
console.log(DEFINE)
```

吐き出された `dist/bundle.js` の当該箇所は

```js
function(e,t){console.log("This is DefinePlugin variable.")}
```

のようになります。  
`DefinePlugin` に渡した object の key に対して property の値に置き換わっているのがわかります。

これまでの確認から

```js
// webpack.config.js
const path = require('path')
const webpack = require('webpack')

const definePlugin = new webpack.DefinePlugin({
  DEFINE: JSON.stringify('This is DefinePlugin variable.'),
  'process.env': {
    DEFINE: JSON.stringify('This is process.env with DefinePlugin variable.'),
  },
})

module.exports = {
  // 省略
}

// index.js
console.log(DEFINE)
console.log(process.env.DEFINE)
```

のように `process.env.***` という定数に値を指定することで `dotenv-webpack` を使わなくても `process.env.***` で参照できます。

結果

```js
function(e,n){console.log("This is DefinePlugin variable."),console.log("This is process.env with DefinePlugin variable.")}
```

また、システム環境変数に渡される環境変数を bundle に含める際などにも使えます。

```js
// $ HOGE='hoge' yarn webpack

const definePlugin = new webpack.DefinePlugin({
  HOGE: JSON.stringify(process.env.HOGE),
})
```

## まとめ

`dotenv-webpack` がどんな挙動になっていて、 `DefinePlugin` の動作も含め関係性を理解しました。  
やりようによっては `DefinePlugin` のみで `dotenv-webpack` のような事が出来そうではありますね。  
今まで両方合わせて使っていた事もあり、自分で混乱する場面もあったのでスッキリしました。

個人的には不要に依存を増やしたくないとかでなければ `.env` ファイルを使う `dotenv-webpack` にまとめる方が管理が楽そうな気がします。これは、 `DefinePlugin` だと環境変数が増えた場合に変更箇所が増えるためです。(システム環境変数も必要だろうし)  
CI/CD で build する場合を考えると、 `dotenv-webpack` の `systemvars` option を true にしておいて、 CI/CD 側では `secrets` などから環境変数を流し込むので良いのかなと思います。（`systemvars` を有効にするとシステム環境変数も読み込んでくれるようになります。）

検証に使ったソースコードは [こちら](https://github.com/hey3/dotenv-webpack-and-define-plugin) です。


oh-my-zsh + anyenv から fish + pure + asdf にした話


ずっと zsh + oh my zsh + anyenv で構成していたのですが、どうも起動が遅い。。  
dotfiles の見直しを含めて fish + pure + asdf の構成にしました。  
その背景、手順、乗り換えてみて良かった事を書いていきます。

## 今までどんな構成だったか

正直記事を書くより結構前に乗り換えていたのでうろ覚えです。。  
git のコミットログから思い出して書いていきます。(dotfiles を git 管理しといて良かった。。。)

今までは zsh 入れて oh my zsh 入れて、 theme を agnoster にするのみの、初期にやりがちな感じで使っていました。  
`.zshrc` にも oh my zsh の設定と `PATH` を記述するだけでした。

anyenv に関しても、 `node` の管理どうしようかってなったときに anyenv で管理したら便利やなってくらいの気持ちで導入していました。

ただ、ある程度使ってくるとどうも遅い。。  
いっそのこと一新してやろうと思ったのが始まりです。

## oh-my-zsh とは

> Oh My Zsh is an open source, community-driven framework for managing your zsh configuration.

とあるように oh-my-zsh は、コミュニティ主導の zsh 構成用のフレームワークとなっています。  
コミュニティ主導ということもあり、各自が便利と思われる設定を取り込ませた盛々なフレームワークです。

つまり、初めて zsh を使う人でもフルカスタマイズな zsh を使うことが出来ます。  
その反面、以下のことも起こります。

- 個人的に不要なカスタマイズまで含まれており遅い
- プラグインによっては長い間更新されていないものがある

自分用にカスタマイズすればよいのですが、不要なものを持っているのは気が引けますね。また、メンテナンスされていないものがあるのも不安になります。

oh my zsh はロード時に以下の流れで処理が行われます。  
[参考 - ohmyzsh/oh-my-zsh.sh](https://github.com/ohmyzsh/ohmyzsh/blob/master/oh-my-zsh.sh)

1. zsh のスクリプト、キャッシュディレクトリの解決
2. 自動アップデートの確認
3. fpath の追加と autoload の実行
4. カスタム構成ファイルの解決
5. plugins を fpath に追加
6. ホストネームの解決
7. dump ファイルの解決
8. config ファイルの読み込み
9. .zshrc の plugin の読み込み
10. custom の読み込み
11. テーマの読み込み

プラグインの多さからロードにかかる時間が長くなります。

初期にサクッと環境を作り出すのには便利だが、慣れてきたら乗り換えた方が良いフレームワークだと思っています。

## anyenv とは

anyenv は **env 系の環境マネージャーの wrapper です。  
複数の ** env の管理が anyenv にまとめられるみたいなイメージです。（実際には \*\*env 毎にバージョン管理を行います）

自分が anyenv を入れていた理由も、言語毎に `nodenv` や `pyenv`、 `rbenv` などを入れており、この管理一つにまとめたいなと思っていたからです。
（ anyenv がナウいっていうのも当時見た。）  
ただ、これにも以下のようなデメリットがあります。

- 対応している言語が少なく感じる
- init が遅い
- メンテナンスがあまりされていない

対応している言語に関しては `anyenv install -l` で確認することが出来ます。  
インストールできる言語としては最低限カバー出来ているなとは思うのですが、 anyenv の特性上 init が無い env に関しては別途対応が必要になったりして不便です。

### oh my zsh と anyenv を組み合わせるとすごく遅い

oh my zsh の遅さと anyenv の遅さが重なって凄く遅いです。（※個人の主観が入っています）

以下は anyenv の init 処理の一部です。  
[参考 - anyenv/anyenv-init](https://github.com/anyenv/anyenv/blob/master/libexec/anyenv-init#L123-L146)

```shell
# Print stderr to show caveat of initialization.
$(anyenv-install --list > /dev/null)

for env in $(anyenv-envs); do
  ENV_ROOT_VALUE=$(echo ${env}_ROOT | tr "[a-z]" "[A-Z]")
  ENV_ROOT="${ANYENV_ROOT}/envs/${env}"

  case "$shell" in
  fish )
    echo "set -gx ${ENV_ROOT_VALUE} \"${ENV_ROOT}\""
    export ${ENV_ROOT_VALUE}="${ENV_ROOT}"
    echo "set -gx PATH \$PATH \"${ENV_ROOT}/bin\""
    ;;
  * )
    echo "export ${ENV_ROOT_VALUE}=\"${ENV_ROOT}\""
    export ${ENV_ROOT_VALUE}="${ENV_ROOT}"
    echo "export PATH=\"${ENV_ROOT}/bin:\$PATH\""
    ;;
  esac

  if { ${ENV_ROOT}/bin/${env} commands | grep -q '^init$' ; } 2> /dev/null  ; then
    echo "$(${ENV_ROOT}/bin/${env} init - ${no_rehash_arg}${shell})"
  fi
done
```

要はインストールされた env の init を anyenv の init 処理時にループで処理しています。

zsh に anyenv を追加する時は `.zshrc` に

```shell
eval "$(anyenv init -)"
```

を追加すると思います。

oh my zsh のロード処理 + anyenv による各 env の init 処理の相乗により起動が遅くなります。  
plugin を入れている限りしょうがないといえばしょうがないですが、シェルの起動時間を早くするとしたら何とか改善したい箇所ですよね。

## fish + asdf に乗り換える

この際ログインシェル毎入れ替えようと思い、何か良いシェルは無いかと探しました。  
色々見た感じ [fish](https://github.com/fish-shell/fish-shell) が良さそうだったので採用しました。

> fish is a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. fish includes features like syntax highlighting, autosuggest-as-you-type, and fancy tab completions that just work, with no configuration required.

使ってみて以下の点が良いなと思いました。

**・補完が良い！**

zsh も plugin の追加で補完は強力なのですが、 fish はデフォルトで強力な補完が効きます。  
`ctrl + f` で使うサジェスト機能も便利です。

**・シンタックスハイライトが優秀**

これまた zsh も plugin でリアルタイムなシンタックスハイライトを利用できるのですが、 fish にはデフォルトで実装されていて、ラグも気になりません。

anyenv から乗り換えるバージョン管理には [asdf](https://github.com/asdf-vm/asdf) を採用しました。

> asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv & pyenv (and more) all in one! Simply install your language's plugin!

これすごく便利！  
asdf は anyenv を使っていたときに比べて以下の点が良いなと思いました。

**・言語以外にも `postgres` や `mongoDB` などのツール群も管理できる**

anyenv の場合言語以外のツール群は別途管理する必要がありました。  
asdf はこの辺もまとめて管理できるので凄く扱いやすい！  
使える plugin は [https://asdf-vm.com/#/plugins-all](https://asdf-vm.com/#/plugins-all) で確認できます。

**・起動が早い**

コードが追えていないので詳細はわかっていないのですが、 anyenv よりも明らかに早いです。

### oh my zsh と anyenv を取り除く

自分の場合は `uninstall_oh_my_zsh` をしつつ oh my zsh、 anyenv zsh の config 周り全て初期化しました。  
zsh も不要だったので uninstall しました。

ここら辺覚えていないのですが、 `.zshrc` など全て初期化しました。

### fish に乗り換える

fish は `brew` を使ってインストールしています。

```shell
$ brew install fish
```

fish をログインシェルに設定するために `/etc/shells` に fish を追加します。

```shell
$ echo /usr/local/bin/fish | sudo tee -a /etc/shells
```

fish をデフォルトシェルに設定します。

```shell
$ chsh -s /usr/local/bin/fish
```

ここまでで一旦 fish への乗り換えは完了です。  
fish の設定は `~/.config/fish/` 以下で行います。

ちなみに設定ファイルは分割可能で、 `~/.config/fish/conf.d/*.fish` が設定ファイルとして読み込まれます。  
`~/.config/fish/conf.d/` 以下に、 `env.fish` や `alias.fish` など設定を分割して管理することで管理がしやすくなります。（いい！）

### fish のプラグインマネージャを入れる

プラグインマネージャには `fisher` を選択しています。  
選んだ理由は `fishfile` というテキストファイルでプラグインを管理できるため、 `dotfiles` 管理的にも良いなと思ったためです。（他のプラグインマネージャでも出来たらすみません。。）

fisher のインストールは以下のコマンドで行います。

```shell
$ curl https://git.io/fisher --create-dirs -sLo ~/.config/fish/functions/fisher.fish
```

### theme plugin を入れる

[Available themes - oh-my-fish/docs/Themes.md](https://github.com/oh-my-fish/oh-my-fish/blob/master/docs/Themes.md) から好きな theme を入れることが出来ます。

`fishfile` に入れたい theme plugin を記述して `fisher` コマンドでインストールします。  
自分の場合は [pure](https://github.com/rafaelrinaldi/pure) を入れています。

```shell
$ echo rafaelrinaldi/pure | tee -a ~/.config/fish/fishfile
$ fisher
```

また、個人的に`AWS_PROFILE` を切り替えて作業することが多いため、コマンドラインに現在の profile を表示するように少し修正しました。

`~/.config/fish/functions/_pure_prompt_aws.fish` を作成して以下を記述しています。

```shell
function _pure_prompt_aws \
    --description 'Print aws profile'

    set --local profile_name
    set profile_name $AWS_PROFILE

    if test -z $profile_name \
      -o $profile_name = "default"
      return
    end

    echo AWS: $profile_name
end
```

作成後、 `~/.config/fish/functions/_pure_prompt_first_line.fish` の `_pure_prompt_first_line` 関数内に `set --local prompt_aws (_pure_prompt_aws)` と追加して表示するようにしています。

### asdf に乗り換える

asdf は git から clone してきます。

```shell
$ git clone https://github.com/asdf-vm/asdf.git ~/.asdf
```

fish の設定ファイルに以下を追加（自分の場合は`~/.config/fish/conf.d/env.fish`）

```shell
source ~/.asdf/asdf.fish
set -g fish_user_paths "/usr/local/sbin" $fish_user_paths
```

これで fish 環境で asdf を使用する準備が整いました。後は必要なものを asdf に入れて好きに使っていくだけです。

`~/.asdfrc` に `legacy_version_file = yes` と書いておくと、 .ruby-version や .node-version を認識してくれるようになるので書いておくと良いです。

## dotfiles の管理も楽になった

以下のファイル群を dotfiles として管理しておくと楽です。

- `~/.config/fish/`: fish の設定ファイルなど
- `~/.tool-version`: asdf の global なバージョン管理
- `~/.asdfrc`

.tool-version を共有しておくことで、 dotfiles の install.sh なんかで `asdf install` とするだけで各 plugin のバージョンのインストールが可能です。  
ただし、事前に asdf で plugin を追加して上げる必要があるので

```shell
if [ ! $(asdf which node) ]; then asdf plugin add nodejs; fi
```

みたいな感じで `asdf install` する前に plugin を追加しておくようにすると良いです。

## まとめ

oh my zsh + anyenv を使っていた頃と比べて、大分起動時のもっさり感が無くなり満足！  
バージョン管理もしやすくなり、 dotfiles の育成も進んだので良かったなという感じでした。

乗り換えた時に記事にすれば良かったのですが、その頃にはブログも完成していなかったので。。  
当時メモしておけば実際の起動時間とか取れていたと思うと悔やまれる（再現するのがめんどかった）。


Next.js で認証機能を実装する


Next.js を使用してログインが必要なページを実装したいなと思ったときに意外と手こずったので備忘録として書いてみます。  
あまり記事がみつからなかったのもあり、原理から理解して実装してみました。(※正しくない内容が含まれているかもしれません。)

## どんなことがしたいか

簡単に言うと管理画面のようなイメージです。  
アカウントを持つユーザのみが閲覧できるページを Next.js で実装してみたかったのです。  
作成したリポジトリは [こちら](https://github.com/hey3/nextjs-sample-auth) です。

[next-auth](https://github.com/nextauthjs/next-auth) や firebase authentication を使っても良いのですが、理解を深めるために自分でやってみようと思った次第です。。  
他の provider を使うとなったらこの辺検討し始めようかなといった感じです。

## 技術スタック

- Next.js: `10.0.3`
- TypeScript: `4.1.2`
- React: `17.0.1`
- mongoDB: `4.7.0`
- typegoose: `7.4.5`
- jsonwebtoken: `8.5.1`
- js-cookie: `2.2.1`

## 認証が必要なページには SSR が必要そう

これを実現するためにはどんな手順になるのかを考えてみました。  
認証が必要なページとは、サーバーへページをリクエストする際にリクエストしたアカウントが認証済みかどうかを判断し、認証済みであればページを返してもらうみたいな流れが必要になります。  
昨今の Next.js では SSG を推している（CDN から提供出来て早いため）が、 SSG では build 時にページを静的に生成しており、リクエスト時にサーバへ `IncomingMessage` を送ることが出来ず、認証情報をサーバへ送ることが出来ません。  
html を貰う前に認証で弾くみたいな仕組みが必要なので、 SSR でやっていく必要があるのかなと思っています。

DOM の mount 時に API でデータ取得時に認証して弾くようにすると、既に DOM が見えてしまっているので良くないです。

### SSR を理解する

Next.js の公式の画像がわかりやすいので引用させて頂きます。  
[引用 - Two Forms of Pre-rendering](https://nextjs.org/learn/basics/data-fetching/two-forms)

![static-generation](https://nextjs.org/static/images/learn/data-fetching/static-generation.png)

SSG も合わせて見直しておきます。  
SSG は build-time にページ HTML をレンダリングしています。  
`getStaticProps` を使った場合に、この関数がサーバ側で実行されビルドされます。

`getStaticProps` が受け取る context は、

```ts
export type GetStaticPropsContext<Q extends ParsedUrlQuery = ParsedUrlQuery> = {
  params?: Q
  preview?: boolean
  previewData?: any
  locale?: string
  locales?: string[]
  defaultLocale?: string
}
```

です。  
これを見てもわかるように、 `IncomingMessage` が使えないのがわかります。

![server-side-rendering](https://nextjs.org/static/images/learn/data-fetching/server-side-rendering.png)

SSR は各リクエスト毎にページ HTML をレンダリングしています。  
`getServerSideProps` を使った場合に、この関数がサーバ側で実行されビルドされます。

`getServerSideProps` が受け取る context は、

```ts
export type GetServerSidePropsContext<Q extends ParsedUrlQuery = ParsedUrlQuery> = {
  req: IncomingMessage
  res: ServerResponse
  params?: Q
  query: ParsedUrlQuery
  preview?: boolean
  previewData?: any
  resolvedUrl: string
  locale?: string
  locales?: string[]
  defaultLocale?: string
}
```

です。

`getServerSideProps` では `IncomingMessage` を使うことが出来、  
この中のヘッダ情報を使うことで認証を行うことが出来そうだと思いやってみたのが今回の実装です。

### getServerSideProps の中で verify を行う

おおまかな流れは以下です。

- ログイン時に jwt を生成する
- jwt を cookie に保存する
- `getServerSideProps` 内で jwt の verify を行うヘルパ関数を用意し、認証が必要なページで使う

cookie に保存するのでそれなりのセキュリティ対策は必要だと思うのですが、サンプルの実装で担保出来ているのかは正直自身が無いです。（レビューして欲しい。。。）

サンプルでは簡略のため API Routes を使用して API を実装し、アカウントの保存には mongoDB を使用しています。  
mongoDB には [Paas-sword](https://paassword.now.sh/) で生成した passwordId を保存します。  
[この辺り - src/pages/api/authenticate.ts](https://github.com/hey3/nextjs-sample-auth/blob/main/src/pages/api/authenticate.ts) の実装になります。

## 実装してみる

実際の実装の流れを記述していきます。

### サーバー側で jwt を発行する

ログイン時に jwt を生成します。

```ts
const AuthService = {
  // ...
  async sign(payload: SignPayload): Promise<string | undefined> {
    return new Promise((resolve, reject) => {
      jwt.sign(payload, process.env.SECRET || 'secret', { expiresIn: '1d' }, (err, token) => {
        if (err) {
          return reject(err)
        }
        return resolve(token)
      })
    })
  },
}
```

のようなメソッドを用意しておいて、ログイン時に以下のような流れで使用します。  
※SECRET 環境変数をクライアント側の js bundle に含まないように注意

```ts
export default async (req: NextApiRequest, res: NextApiResponse): Promise<void> => {
  if (req.method !== 'POST') {
    return res.status(405).end(`Method ${req.method} is not allowed.`)
  }
  await DatabaseService.connect()

  const { email } = req.body
  const user = await User.findOne({ email })

  const token = await AuthService.sign({
    id: user._id,
  })
}
```

`sign` の payload には mongoDB に登録した users ドキュメントの ObjectId を渡します。  
jwt は base64 でエンコードされているだけなので、あまり重要なデータを入れてはいけません。

受け取った jwt を Cookie に保存しておきます。  
サンプルでは [js-cookie](https://github.com/js-cookie/js-cookie) を使ってクライアント側で保存しています。  
[nookies](https://github.com/maticzav/nookies) を使って cookie の扱いをクライアントとサーバで共通にしてもよかったのかなとは思ったのですが、今回は使っていません。

### getServerSideProps と各 API で jwt を使った Auth を行う

認証が必要なページの `getServerSideProps` 内で jwt の verify を行うヘルパ関数を用意しておきます。  
認証が必要なページを実装する際には、このヘルパ関数で wrap してあげるだけでよいので楽になります。

```ts
type InnerGetServerSideProps<P extends { [key: string]: unknown }> = (
  context: GetServerSidePropsContext
) => Promise<{ props: P }>

export const withAuth = <P extends { [key: string]: unknown }>(
  inner?: InnerGetServerSideProps<P>
): GetServerSideProps => {
  return async ctx => {
    const {
      req: { headers },
      res,
    } = ctx
    const isAuthenticated = await validateTokenCookie(headers)
    if (!isAuthenticated) {
      res.setHeader('Location', '/login')
      res.statusCode = 307
    }

    return inner ? inner(ctx) : { props: {} }
  }
}
```

`validateTokenCookie()` では headers から cookie -> jwt を取り出し `jsonwebtoken` の [verify 関数を使用して verify をしています](https://github.com/hey3/nextjs-sample-auth/blob/main/src/services/auth.ts#L47) 。

認証が必要なページの実装側で

```ts
export const getServerSideProps: GetServerSideProps = withAuth()
```

みたいにしてやれば OK です。

認証に加えて SSR でレンダリング時にデータの取得を行いたい場合は、

```ts
export const getServerSideProps: GetServerSideProps = withAuth(async () => {
  const response = await fetch('/hoge').then(res => res.json())

  return {
    props: {
      hoge: response.hoge,
    },
  }
})
```

みたいな感じで withAuth の中で普段どおりの実装を行うことで可能になるようにしています。

API には data fetch 時に Authorization ヘッダに載せてあげるようにすると良いと思います。

```ts
const response = await fetch('/fuga', {
  // ...
  headers: {
    Authorization: Cookies.get('クッキーに保存したトークン'),
  },
})
```

## まとめ

SSR の場合の認証周りの知見が少なかったので、発想が思いつくまで結構苦労しました。。  
今回の実装の懸念点としては、毎回 verify を噛ましているのでパフォーマンスの観点ではどうなのかなとも思っています。  
しょうがないのかなとも思いつつ、、良い方法がありましたら DM にて教えて頂けると嬉しいです。


hey3.dev

Blog Posts