[create-react-app](https://github.com/facebookincubator/create-react-app)で作っている React アプリを Circle CI 2.0 でビルドする手順について紹介します。

今回説明するのは、CircleCI 2.0 を使う上での大まかな流れについてです。



## 前提条件

フロントエンドのプロジェクトには`test`と`build`のタスクがあって、全て`npm run`で実行できるとします。
またデプロイについては、`build`タスクで 1 つのバンドルファイルを作成して S3 にデプロイします。

## 定義ファイルを作成する

まずは定義ファイルを作成する必要があります。設定ファイルは`.circleci`フォルダの中に`config.yml`を作成して定義していきます。

```
root
  .circleci
    config.yml
```

定義ファイルのシンタックスについては v1.0 と比べると結構変わっているので注意が必要です。
Slack の作業ログを見ると、Dashboard のどこかで定義ファイルが生成できたようですが、どこだか忘れてしまいました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/circleci2.0-1.png)

定義ファイルを生成すると次のようなファイルが作成されます。

デフォルトでは CircleCI が準備した Docker image を使います。(`image: circleci/node:8.9`の部分)
node, npm, yarn は既に image に含まれているので、最小構成であればこれで大丈夫だと思います。

```
# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
  build:
    docker:
      # specify the version you desire here
      - image: circleci/node:8.9

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/mongo:3.4.4

    working_directory: ~/workspace

    steps:
      - checkout

      # Download and cache dependencies
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}
          # fallback to using the latest cache if no exact match is found
          - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      # run tests!
      - run: yarn test
```

定義ファイルの書き方については公式サンプルプロジェクトを見てください。

- <https://github.com/CircleCI-Public/circleci-demo-javascript-express>

## Docker image を作成する

**（この工程は必要な場合のみです。）**

デフォルトでは CircleCI が準備した Docker image を使うのですが、これをさらにカスタムしてツールなどを導入したい場合は、新しく Docker image を準備する必要があります。

自分の場合、S3 にデプロイする場合は AWS-CLI ツールを利用するので、これをインストールした image を作成する必要がありました。
image を作成する際は、`circleci/node:8.9`を継承することができますので、ぜひそうしましょう。

```
FROM circleci/node:8.9

# ここから下にいろいろ定義する
...
```

実際に作成した image はこちらです。

- <https://hub.docker.com/r/mitsuruog/cool-build-frontend/>

docker image の作成方法についてはこちらを参照してください。

- [docker image を docker hub に公開する方法](https://blog.mitsuruog.info/2017/11/way-to-publish-docker-image)

## Job を定義する

次に Job を定義します。この後の手順としては、`Job`を定義してこれをワークフローの中で順番に呼び出していきます。

Job とは、CircleCI の中で再利用できると便利だなと思う一連のタスクをまとめたものです。例えば、`test` とか`test and build`などがそれにあたります。
とにかく次のワークフローの中ではこの**ジョブ名**を利用してフローを作成するので、このことを意識して定義するといいと思います。

基本的には`jobs:`の直下にタスク名(上の例では`build:`)を定義して、`steps:`の中にやりたいことを順番に書いていきます。
この辺りは 1.0 をやったことがある人であれば、想像できると思います。

```
version: 2
jobs:
  build:
    steps:
      - run step1
      - run step2
      - run step3
      ...
```

細かな設定は公式ドキュメントを参考にしてください。

- [Configuration Reference](https://circleci.com/docs/2.0/configuration-reference/)

## ワークフローを定義する

最後に定義した Job をワークフローとして組み立てていきます。

基本的には`workflows:`の直下にワークフロー名を定義して、`jobs:`の中にやりたいことを順番に書いていきます。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
      - deploy
```

ちなみに`test`などの、次の Job に進む前に完了していなければならない Job がある場合、`requires`を使うことで表現することができます。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
          requires:
            - test
      - deploy
          requires:
            - build
```

この場合、`test` -> `build` -> `deploy`の順にワークフローが実行されます。
ワークフローを定義する場合、同じ階層にある Job は並列に実行されるため、`requires`でフローの制御は必須だと思います。

また、特定のブランチのみ実行させたい場合は、`filters`と`branches`を組み合わせることで表現可能です。

```
workflows:
  version: 2
  test_build_and_deploy:
    jobs:
      - test
      - build
          filters:
            branches:
              only:
                - develop
```

この場合は`develop`プランチの場合のみ build の Job が実行されるようになります。

定義したワークフローは CircleCI 上の「WORKFLOWS」にて確認することができます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/circleci2.0-2.png)

## おまけ

Circle CI のデフォルトのマシンリソースは`medium`(CPU 2.0 RAM 4GB)となっていて、最近のフロントエンドのテスト、デプロイにおいてはスペック不足感が否めません。

> CPU はコア数かな？

自分の場合は、テストで js-dom を使っているのですが、頻繁に次のようなエラーが発生していました。

```
ENOMEM: not enough memory, read
```

そんな時は、`resource_class`でマシンスペックをあげることができます。
しかし、今のところ Circle CI のカスタマーサポートに依頼する必要があります。詳しくはこちらを見てください。

- <https://circleci.com/docs/2.0/configuration-reference/#resource_class>

> 有効にしたい Organization 名と一緒に依頼すると割と早めに対応してくれました。Circle CI のカスタマーサポート素晴らしい！！

> ![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/circleci2.0-3.png)

> とはいえ、将来的には`resource_class`はプレミアム機能になるかもしれないです。要注意！

## まとめ

CircleCI 2.0 でフロントエンドをビルドするための大まかな手順でした。
本題とは全く関係ないのですが、Circle CI のカスタマーサポート迅速でよかったなー。

CircleCI 2.0 の公式ドキュメントについてはこちらを参照してください。

- <https://circleci.com/docs/2.0/>

Circle CI 2.0でフロントエンドをビルドする

ニッチ過ぎて誰得なのか全くわからないのですが、同じようなことで苦しめられるであろう**未来の誰かのため**に、ここに手がかりを残しておきます。



> 正直このあたりのライブラリの変化が早過ぎるので、この情報がいつ風化するかわからないのだけれど。。。

## はじめに

詰まるところ[create-react-app](https://github.com/facebookincubator/create-react-app)をベースに React アプリを作っているのですが、Redux の`connect`を使っているコンポーネントをテストする際に、次のようなエラーが出ました。

これの解決方法を残しておきます。

```
Invariant Violation: You must pass a component to the function returned by connect. Instead received undefined
```

> <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

> これを読むと書いてあるんですが、redux store と一緒テストをする場合は、`<Provider>`でラップする必要があります。

今回は、redux store と切り離して純粋なコンポーネントとしてテストする場合の解決方法です。

## サンプルコード

例えば、こんなコードです。(ラフに書いたので、このままだと動かないかも)

Component.jsx

```
import React from 'react';
import { connect } from 'react-redux';

class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}

const mapStateToProps = (state) => {
  name: state.name,
};

const wrappedComponent = connect(mapStateToProps)(Component);

export default wrappedComponent;
```

Component.spec.jsx

```
import * as React from 'react';
import { shallow } from 'enzyme';
import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## 解決方法

上のやり方では、`Component.jsx`の default export が connect でラップされたコンポーネントなので、上のエラーが発生していました。

コンポーネント自体を connect なしでテストするためには、connect でラップされたものの他に、コンポーネント自体も export する必要があります。

このコンポーネントをテストで利用します。これでエラーも発生しません。

Component.jsx

```diff
- class Component extends React.Component {
+ export class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}
```

Component.spec.jsx

```diff
import * as React from 'react';
import { shallow } from 'enzyme';
+ import { Component } from './Component';
- import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## まとめ

まず、公式ドキュメントに目を通せ！ということでした。

- <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

でも、実際に一度困ってみないと、言っている意味がわからないものですねー。

react-reduxのconnectを使ったコンポーネントをテストする時にInvariant Violationが発生して困っている人のためのヒント

よく忘れるシリーズ。

AWS の特定の S3 バケットにだけアクセスできる IAM ユーザーを作る方法です。



## 想定される用途

自分の場合、最近のフロントエンドは SPA を作ることが多いので、フロントエンドのコードを Webpack で bundle にビルドして S3 へデプロイします。

この辺りは CI サービスを利用して自動化しているのですが、その時に AWS の IAM を作成し、そのアクセスキーを使って特定の S3 バケットにデプロイするようにします。

> 特定のバケットにだけアクセスできるようにしているのは、不慮の事故で他の S3 バケットに影響を及ぼさないためです。

## IAM ユーザーの作り方

IAM ユーザーの作り方は至って単純で、AWS のコンソールにログインして IAM ユーザーを作成すればいいです。

ところが、**特定の S3 にのみアクセスできる**ようにするためには、**カスタムポリシー**を作成して IAM ユーザーに適用する必要があります。
しかしまぁ、フロントエンドエンジニアの自分としては、AWS のポリシーの JSON を触る機会などあまりないので、その書き方を毎回すっかり忘れるわけです。

というわけで、今回はこの面倒な JSON を忘れないようにするのがこの記事の目的です。

特定の S3 バケットにのみアクセスできるようにするには、次のような JSON をポリシーに設定します。

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
          "arn:aws:s3:::<bucket-name>",
          "arn:aws:s3:::<bucket-name>/*"
      ]
    }
  ]
}
```

- `<bucket-name>`の部分には、アクセスを許可したい S3 バケット名を指定してください。
- `<bucket-name>/*`となっているのは、サブディレクトに対してもアクセスを許可するための設定です。

このポリシーを設定した IAM ユーザーのアクセスキーを、CI サービスで使えば特定の S3 バケットに対してデプロイできるようになります。

## まとめ

AWS の特定の S3 バケットにだけアクセスできる IAM ユーザーを作る方法でした。

CI 周りの設定はプロジェクトを初期構築するときにやるので、次やろうとした時には大抵忘れています。
なので、備忘も兼ねて記事にしてみました。

特定のS3バケットにだけアクセスできるIAMユーザーを作る

[react-router v4](https://github.com/ReactTraining/react-router)の小ネタ。



## やりたかったこと

> 昔は`<IndexRoute />`があったんだけどね。。。

例えば、`/users/1`という URL にアクセスがきた時に`/users/1/info`のページを表示させたい場合。

`<Redirect />`の中にこんな感じで書くと動くと思ったんですが。。。

```
<Redirect from="/users/:id" to="/users/:id/info" />
```

## 実際の挙動

実際にリダイレクトされた URL は`/users/:id/info`でした。

なんてこったい！

## 解決方法

一度`<Route />`で囲ってから`render`を使ってリダイレクトします。
こんな感じでできました。が、正直めんどくさい。

```
<Route
  path="/users/:id"
  exact={true}
  render={({ match }) => (
    <Redirect to={`/users/${match.params.id}/info`} />
  )}
/>
```

## まとめ

前のプロジェクトでは v2 系を使っていたのですが、v4 は結構変わってて割と大変ですね。（白目

> 同じようなこと考えて PR 送ってくれている人いるんですが、こりゃマージされないな。。。
>
> - <https://github.com/ReactTraining/react-router/pull/5368>

react router v4のRedirectでURLパラメータを使う

TypeScript を使っていると、結構必要になる型定義ファイル。
型定義が存在しなかったり、古かったりするライブラリを使って、苦労した経験があるひとは多いのではないでしょうか。

今回は、DefinitelyTyped にコントリビュートする機会が最近増えたので、個人的な手順をまとめておきます。



## はじめに

まず、今回は新しい型定義ファイルを作成するケースを想定しています。

コントリビュートの仕方については、まず公式ドキュメントをさらりと眺めておいてください。
ただ、結構わかりにくいと思うので、これから順を追って説明していきます。

- <https://github.com/DefinitelyTyped/DefinitelyTyped>

それから型定義が存在しない事を確認しましょう。

- <https://microsoft.github.io/TypeSearch/>

## 事前準備

型定義の Generator があるのでインストールしておく。
基本なくても大丈夫だと思いますが、フォルダやファイルヘッダーなど自動生成してくれて便利なので、インストールしておきましょう。

```
npm install -g dts-gen
```

DefinitelyTyped のリポジトリを clone して、トップのフォルダで`dts-gen`コマンドを実行する。

```
dts-gen --dt --name my-package-name --template module
```

> `--template`の部分はいくつか指定があるのですが、あまり詳しく知らないです。
> （この辺り、どの template 使ったらいいか、わかりやすいドキュメントがあるといいんだけどなー。）

> (2017.11.23 追記)テンプレートっぽいの見つけたので貼っておきます。
>
> - <https://github.com/Microsoft/TypeScript-Handbook/tree/master/pages/declaration%20files/templates>

generate した結果はこんな感じで、`types`の下にディレクトリが作成されています。

```
DefinitelyTyped
  types
    my-package-name
      index.d.ts
      my-package-name-test.ts
      tsconfig.json
      tslint.json
```

## index.d.ts を書く

さぁ、ここからは実際に型定義を作成していきます。型定義は`index.d.ts`に定義します。

型定義の書き方についてはここでは紹介しませんが、内部構造が似ているライブラリを参考にすることが多いです。

## index.d.ts をデバックする

型定義ファイルが出来上がったら、実際にプロジェクトに投入して正しく機能するかデバックします。実は、`npm`からインストールされた型定義ファイルは、`node_modules/@types`の中に格納されています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/DefinitelyTyped.png)

そのため、`@types`の下にライブラリ名と同じフォルダを作成して、その中に作成した`index.d.ts`を配置すると、あたかも`npm`インストールしたような振る舞いをします。

## test を書く

デバックも完了したら、PR を作成する準備に入ります。

コントリビュートするためには、型定義のテストを書く必要があります。テストは上の`my-package-name-test.ts`に書きます。

> テストというよりは、実際にライブラリを利用するようなコードを書きます。ライブラリの利用例をバリエーション豊かに書くといった感じです。

型定義で定義した内容を（なるべく）網羅したテストを書きます。

手前味噌ですが、自分が書いたテストを張っておきます。これも他のライブラリを見ながら書いていきます。

```
import * as React from "react";
import Alert from "react-s-alert";

const config = {
    position: "top",
    offset: 100,
    stack: {
        limit: 3,
        spacing: 50,
    },
    effect: "genie",
    beep: {
        info: "beep.mp3",
        error: "beep.mp3",
        warning: "beep.mp3",
        success: "beep.mp3",
    },
    timeout: 1000,
    html: true,
    onClose: () => {},
    onShow: () => {},
    customFields: {},
};

class Test extends React.Component {
    render() {
        return (
          <div>
              <Alert />
              <Alert
                  {...config}
              />
          </div>
        );
    }
}

Alert.info("I am a info message.", config);
Alert.error("I am an error message.", config);
Alert.warning("I am a warning message.", config);
Alert.success("I am a success message", config);

const index = Alert.info("Hello");
Alert.close(index);

Alert.closeAll();
```

(2017/11/15 現在のコードなので古くなっているかもしれません。最新はこちらから見れます)

- <https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react-s-alert/react-s-alert-tests.tsx>

## Lint チェックをする

テストを書いたら Lint ツールを実行して最終確認をします。

```
npm run lint my-package-name
```

## PR を作る

最後に DefinitelyTyped に対して PR を作成したら完了です。レビューなどで指摘がなければ、DefinitelyTyped にマージされて使えるようになると思います。

## まとめ

型定義を作って DefinitelyTyped にコントリビュートする手順でした。

初めての時にプロセスを理解するまでに結構時間がかかったのでまとめてみました。
個人的には型定義のデバック方法を知れたのが一番の収穫でした。

いつもお世話になっている型定義なので、気軽に貢献できると嬉しいですね。

DefinitelyTypedに型定義ファイルを作ってコントリビュートする手順

docker image を docker hub に公開する方法についての小ネタです。



お仕事で docker image を作成して公開必要があったのですが、やり方よく知らなかったので、同僚の docker 得意なエンジニアに教えてもらいました。

## docker image を作成する

まずは、docker image を作成します。

今回は CircleCI 2.0 で使うフロントエンドビルド用の image を作成するため、ベースの image に`circleci/node:8.9`を利用しました。

BuildDockerfile

```
FROM circleci/node:8.9

ENV PATH /home/circleci/.local/bin:${PATH}

# Install AWS CLI
RUN sudo apt-get install python-dev
RUN sudo curl -O https://bootstrap.pypa.io/get-pip.py
RUN python get-pip.py --user
RUN pip install awscli --upgrade --user
```

image ファイルができたら、docker image をビルドします。

```
$ docker build -f BuildDockerfile .
```

ビルドが終わったら image のリストを表示して、image id を覚えておきます。今回の場合は、一番上にある`<none>`が作成した image です。

```
$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
<none>              <none>              680c58dbd0f9        29 seconds ago      986MB
circleci/node       8.9                 66a65e08d915        9 hours ago         894MB
codeprep/sqlite     latest              0c3ec62e9c37        7 days ago          13.6MB
...
```

> 直前に作った image であれば、一番上に表示されると思います。

## docker image をテストする

docker image をテストします。

テストの方法は「[docker image の中身をデバックする方法](https://blog.mitsuruog.info/2017/11/way-to-debug-docker-image)」にあるとおり image の中に入ってデバックします。

> image 名には、上で取得した image id を指定します。

## docker にログインする

ここからは、image を公開するための準備です。

[docker hub](https://hub.docker.com/)のアカウントで docker にログインしておきます。

```
$ export DOCKER_ID_USER="mitsuruog"
$ docker login
```

`DOCKER_ID_USER`には docker hub にユーザー名を設定しておきます。あとで使います。（なくても大丈夫ですが。。。）

## docker image にタグをつける

docker image にタグ（名前）を付けます。

```
$ docker tag [image name] $DOCKER_ID_USER/cool-build-frontend
```

`image name`には、上で取得した image id を指定し、`cool-build-frontend`に好きな名前を設定します。

タグつけが終わったら image のリストを表示して image にタグが付いていることを確認します。

```
$ docker images

REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
mitsuruog/cool-build-frontend   latest              680c58dbd0f9        2 minutes ago       986MB
circleci/node                   8.9                 66a65e08d915        9 hours ago         894MB
codeprep/sqlite                 latest              0c3ec62e9c37        7 days ago          13.6MB
```

## docker image を公開する

最後に image を docker hub に公開します。

```
$ docker push mitsuruog/cool-build-frontend
```

結果は、こんな感じです。

- <https://hub.docker.com/r/mitsuruog/cool-build-frontend/>

## まとめ

ほぼ、自分用のメモですね。

手順については他にも色々あると思うので、あくまでやり方の 1 つとして参考してください。

docker imageをdocker hubに公開する方法

docker image を作る際のデバック方法についての小ネタです。



お仕事で docker image を作成する必要があったのですが、docker image のコンテナ中に入ってデバックする方法をよく知らなかったので、同僚の docker 得意なエンジニアに教えてもらいました。

## docker コンテナへの入り方

デバックするために docker image のコンテナの中に入る必要があるので、次の`docker run`コマンドを実行します。

```
docker run --rm -it [image name] /bin/bash
```

それぞれのオプションは次の通りです。

`--rm`: docker run 終了時に run で起動した docker コンテナを削除します。これをしない場合、コンテナが残ってしまうため、デバック目的であれば付けておいた方がいいと思います。

`-it`: `i`はインタラクティブモード、`t`は**tty**と呼ばれるもので(あまり詳しくわかってない)両方のオプションを設定するといい感じのコマンド入力インターフェースになるので、基本は付けておいた方が良さそうです。

`[image name]`: デバックしたい docker image 名を指定します。

`/bin/bash`: docker run で実行するアプリケーション。この例では**bash**が起動します。特にデバック目的であれば変える必要がないかと。。。

> image によっては**bash**がない場合があるので、その場合は`/bin/sh`に変えてください。

## コンテナからの脱出方法

このコマンドを実行します。

```
exit
```

## まとめ

今までよく分からなかった docker image の中のデバック方法について知る事ができたので、本当によかったです。