1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

個人開発のReactアプリに、GitHub ActionsでCIを入れました。

個人開発だと、最初はローカルで動けば十分だと思いがちです。

ただ、少しずつ機能が増えてくると、

  • lintを通し忘れる
  • 型エラーに気づかない
  • テストを回し忘れる
  • buildが通らないままpushしてしまう

ということがあります。

そこで、pushやpull requestのタイミングで、最低限のチェックが走るようにしました。

やりたいこと

今回CIで実行したいのは以下です。

npm ci
npm run lint
npm run typecheck
npm test
npm run build

つまり、

  • 依存関係をクリーンに入れる
  • ESLintを通す
  • TypeScriptの型チェックを通す
  • テストを実行する
  • 本番ビルドが通るか確認する

という流れです。

npm scripts

まず、package.json に必要なscriptsを用意します。

{
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "preview": "vite preview"
  }
}

build でも型チェックをしていますが、CIでは typecheck を独立して実行します。

エラーの原因が分かりやすくなるからです。

workflowファイルを作る

GitHub Actionsの設定は .github/workflows/ci.yml に書きます。

name: CI

on:
  push:
  pull_request:

jobs:
  ci:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run lint
        run: npm run lint

      - name: Run typecheck
        run: npm run typecheck

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

これで、pushやpull requestのたびにチェックが走ります。

npm ciを使う理由

CIでは npm install ではなく npm ci を使います。

npm ci

npm cipackage-lock.json をもとに、依存関係をクリーンにインストールします。

ローカルとCIで依存関係がズレにくくなるので、CIでは基本的に npm ci を使うのが扱いやすいです。

Node.jsのバージョンを固定する

ローカルとCIでNode.jsのバージョンが違うと、意図しないエラーが出ることがあります。

そのため、CI側でもバージョンを指定します。

- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: npm

個人開発でも、Node.jsのバージョンは明示しておくと安心です。

lint / typecheck / test / build を分ける

CIでは、1つのコマンドにまとめることもできます。

npm run lint && npm run typecheck && npm test && npm run build

ただ、GitHub Actionsのstepを分けておくと、どこで失敗したのか分かりやすくなります。

lintで落ちたのか
型チェックで落ちたのか
テストで落ちたのか
buildで落ちたのか

原因がすぐ見えるので、stepは分ける方が好みです。

CIを入れてよかったこと

個人開発でもCIを入れてよかったです。

特に、以下の安心感がありました。

  • buildが通る状態を保ちやすい
  • 型エラーにすぐ気づける
  • push前の確認漏れが減る
  • READMEに「CIが通る」前提で書ける
  • 公開リポジトリとして少し安心感が出る

小さいアプリでも、CIがあるとリポジトリの信頼感が少し上がります。

個人開発でもCIは重すぎない

最初は、個人開発にCIは少し大げさかと思っていました。

ただ、設定自体はそれほど大変ではありません。

.github/workflows/ci.yml を1つ置くだけで、最低限のチェックが自動化できます。

特に、React + TypeScriptのようにビルドや型チェックがあるプロジェクトでは、CIがあるだけで安心感がかなり違います。

まとめ

Vite + React + TypeScriptの個人開発にGitHub ActionsでCIを入れました。

やっていることはシンプルです。

npm ci
npm run lint
npm run typecheck
npm test
npm run build

個人開発でも、

  • buildが通るか
  • 型エラーがないか
  • lintが通るか
  • テストが通るか

を自動で確認できるのは便利です。

小さいリポジトリでも、公開するならCIを入れておくと安心だと思いました。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?