diff --git a/.cursor/rules/all.mdc b/.cursor/rules/all.mdc new file mode 100644 index 00000000..45ae78e7 --- /dev/null +++ b/.cursor/rules/all.mdc @@ -0,0 +1,143 @@ +--- +description: +globs: +alwaysApply: true +--- +# プロジェクト概要 + +このリポジトリは、Zennの記事とサンプルコードを1つのモノレポで管理しています。サンプルコードが常に動作する状態を維持するために継続的にメンテナンスされています。 + +## 技術スタック + +- **パッケージマネージャー**: Bun +- **テストフレームワーク**: Vitest +- **言語**: TypeScript +- **フロントエンドフレームワーク**: React +- **CI/CD**: GitHub Actions +- **コードカバレッジ**: Codecov + +## 主要機能 + +- 記事とサンプルコードを統合したモノレポ構造 +- Vitestによる自動テスト +- vitest-axeによるアクセシビリティテスト +- コードカバレッジレポート +- TypeScriptサポート +- Reactコンポーネントのテスト + +## プロジェクト構造 + +### ルートディレクトリ +- `/articles`: Zennの記事を格納 + - 各記事はMarkdownファイルとして管理 + - フロントマターで記事のメタデータを管理 + - 画像は`/articles/images`に配置 + +- `/src`: サンプルコードの実装を格納 + - 各サンプルは独立したディレクトリとして管理 + - テストファイルは実装と同じディレクトリに配置 + - 共通の設定ファイルはルートに配置 + +### サンプルプロジェクト +- `/src/jest-same-example-next`: Jestのテストファイル構成例 + - Next.jsプロジェクトでのテストファイル配置例 + - テストと実装を同じディレクトリに配置する構成 + +- `/src/jest-same-example-rollup`: Rollupを使用したJestの例 + - Rollupでバンドルするプロジェクトのテスト構成例 + - モジュールバンドリング時のテスト設定例 + +- `/src/react-if-sample`: Reactのif文パターン + - 条件分岐の実装パターン集 + - コンポーネントの条件付きレンダリング例 + +- `/src/jest-ts-auto-mock-sample`: モックデータ生成の例 + - TypeScriptの型定義からモックデータを自動生成 + - テストデータの管理方法の例 + +## 開発環境のセットアップ + +```bash +# .node-versionで指定されたNode.jsバージョンをインストール +$ cat .node-version | nodenv install + +# Bunで依存関係をインストール +$ bun install +``` + +## テスト + +プロジェクトではVitestを使用してテストを行い、以下の機能を提供しています： +- Happy DOMテスト環境 +- Reactテストサポート +- vitest-axeによるアクセシビリティテスト +- Istanbulによるコードカバレッジレポート +- Canvasモックサポート + +### テストの書き方 +- テストファイルは実装ファイルと同じディレクトリに配置 +- テストファイル名は`*.test.ts`または`*.test.tsx`の形式 +- コンポーネントテストは`__tests__`ディレクトリに配置可能 +- テストカバレッジは80%以上を維持 + +## CI/CD + +- GitHub Actionsによる自動テスト +- Codecovによるカバレッジレポート +- 自動テストワークフローバッジ +- カバレッジバッジ + +## 記事一覧 + +このリポジトリには以下の記事が含まれています： +- Jestのテストファイル構成 +- Reactのif文パターン +- モックデータ生成 +- Laravel API環境の構築 +- Next.js/Serverless FrameworkでのISR実装 +- PlaywrightによるE2Eテスト +- テストとStorybookのセットアップ +- axeによるアクセシビリティテスト + +## 最近の移行 + +プロジェクトは最近以下の移行を行いました： +- パッケージマネージャーをYarnからBunへ +- テストフレームワークをJestからVitestへ + +これらの移行により以下の改善が実現されました： +- パッケージインストール速度の向上 +- 設定の簡素化 +- TypeScriptサポートの強化 +- テスト実行パフォーマンスの向上 + +## 開発フロー + +### 新規機能追加 +1. 新しいサンプルプロジェクトのディレクトリを作成 +2. 必要な依存関係をインストール +3. テストを実装 +4. コードカバレッジを確認 +5. PRを作成 + +### 記事の追加・更新 +1. `/articles`にMarkdownファイルを作成 +2. フロントマターを設定 +3. サンプルコードとリンク +4. プレビューで確認 +5. PRを作成 + +## トラブルシューティング + +### よくある問題 +- **Bunのインストールエラー** + - Node.jsのバージョンを確認 + - `bun install`を再実行 + +- **テストの実行エラー** + - `node_modules`を削除して再インストール + - テスト環境の設定を確認 + +- **TypeScriptの型エラー** + - `tsconfig.json`の設定を確認 + - 型定義ファイルの更新 \ No newline at end of file diff --git a/.gitignore b/.gitignore index 80c5df97..4727c5e6 100644 --- a/.gitignore +++ b/.gitignore @@ -57,3 +57,4 @@ test-results trace.zip .jest-test-results.json junit.xml +settings.local.json \ No newline at end of file diff --git a/.textlintrc b/.textlintrc index d2643c3f..85a94af2 100644 --- a/.textlintrc +++ b/.textlintrc @@ -8,8 +8,36 @@ "preset-ja-technical-writing": { "sentence-length": { "max": 200 + }, + "ja-no-mixed-period": { + "severity": "warning" } }, - "spellcheck-tech-word": true + "spellcheck-tech-word": true, + "no-doubled-joshi": true, + "ja-no-redundant-expression": true, + "ja-no-successive-word": true, + "ja-unnatural-alphabet": true, + "max-ten": { + "max": 4 + }, + "max-kanji-continuous-len": { + "max": 6 + }, + "terminology": true, + "no-todo": true, + "no-empty-section": true, + "abbr-within-parentheses": true, + "common-misspellings": true, + "no-dead-link": { + "checkRelative": false, + "ignore": ["http://localhost*"] + }, + "no-mix-dearu-desumasu": { + "preferInHeader": "", + "preferInBody": "ですます", + "preferInList": "", + "strict": false + } } } diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 00000000..5433c997 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,107 @@ +# CLAUDE.md + +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. + +## プロジェクト概要 + +Zenn の記事とサンプルコードを 1 つのモノレポで管理しているリポジトリです。サンプルコードは常に動作する状態を維持するため継続的にメンテナンスされています。`/articles`に Zenn 記事（フロントマター付き Markdown）、`/src`にサンプルコード実装が格納されています。 + +## 主要コマンド + +### 開発環境セットアップ +```bash +# .node-versionで指定されたNode.jsバージョンをインストール +cat .node-version | nodenv install + +# Bunで依存関係をインストール +bun install +``` + +### テスト実行 +```bash +# 全ワークスペースのテストを並列実行 +bun run vitest + +# CI用（カバレッジとJUnit出力付き） +bun run vitest-ci + +# ウォッチモードでテスト実行 +bun run vitest-watch + +# 単一テストファイルの実行（ワークスペースディレクトリから） +bunx vitest path/to/test.spec.tsx +``` + +### 型チェックとリント +```bash +# 全ワークスペースの型チェック +bun run type-check + +# ウォッチモードで型チェック +bun run type-check-watch + +# TypeScript/JavaScriptファイルのリント +bun run lint-ts + +# Markdown記事のリント +bun run lint-md + +# 全ての問題を自動修正 +bun run fix +``` + +### ビルドと開発 +```bash +# 全ワークスペースを並列ビルド +bun run build + +# Zenn記事をローカルでプレビュー +bun run start + +# 開発サーバー起動（src/next-sampleなど特定ワークスペースから） +bun run dev +``` + +### PlaywrightでのE2Eテスト +```bash +# Playwrightブラウザをインストール +bun playwright install + +# E2Eテスト実行（src/playwright-sampleから） +bun run e2e-chromium +``` + +## アーキテクチャ + +### モノレポ構造 +- Bun ワークスペースと連携した Lerna で複数パッケージを管理 +- `/src`内の各サンプルプロジェクトは独立したワークスペース（独自の`package.json`を持つ） +- ルートレベルのスクリプトが全ワークスペースでの並列実行を統括 + +### テストアーキテクチャ +- **フレームワーク**: パフォーマンスと設定の簡素化のため Jest から Vitest へ移行 +- **テスト環境**: 高速 DOM テスト用の Happy DOM +- **Reactテスト**: `@testing-library/react`と`@vitejs/plugin-react`を使用 +- **アクセシビリティテスト**: 自動アクセシビリティチェック用の`vitest-axe`を統合 +- **カバレッジ**: Codecov 統合付きの Istanbul プロバイダー +- **テストファイル**: 実装ファイルと同じ場所に配置（例：`Main.tsx`と`Main.spec.tsx`） + +### CI/CDパイプライン +- **GitHub Actions**: master へのプッシュと PR 時の自動テスト +- **テスト実行**: リント、型チェック、ユニットテスト、end-to-end テストを実行 +- **カバレッジレポート**: Codecov へ自動アップロード +- **Chromatic統合**: Storybook コンポーネントのビジュアルリグレッションテスト +- **Launchable統合**: テストインテリジェンスとフレーキーテスト検出 + +### 主要な技術的決定 +- **パッケージマネージャー**: 高速インストールと組み込み TypeScript サポートのため Yarn から Bun へ移行 +- **テストフレームワーク**: ESM サポート改善と実行速度向上のため Jest から Vitest へ移行 +- **設定**: ルートの共有 Vitest 設定とワークスペース固有のオーバーライド +- **コード品質**: ESLint と Prettier、Husky でのプリコミットフック、lint-staged での増分リント + +## 最近の移行 + +プロジェクトは最近大規模な移行を実施： +1. **Yarn → Bun**: パッケージインストール速度の向上とスクリプトの簡素化 +2. **Jest → Vitest**: TypeScript サポート改善、テスト実行高速化、設定の簡素化 +3. これらの移行により設定ファイルがクリーンになり、開発体験が向上 \ No newline at end of file diff --git a/articles/axe-accessibility.md b/articles/axe-accessibility.md index 9f7ce1b7..c730589f 100644 --- a/articles/axe-accessibility.md +++ b/articles/axe-accessibility.md @@ -10,9 +10,9 @@ published: true `jest-axe` ・ `@axe-core/playwright` を使用したテストを CI で回すことで、アクセシビリティを継続的に担保していくことができます。 -## jest axeを活用してコンポーネントのアクセシビリティ担保 +## Jest axeを活用してコンポーネントのアクセシビリティ担保 -`jest-axe`を使用することでコンポーネント単位でアクセシビリティテストをできます。 +`jest-axe`を使用することで、コンポーネント単位のアクセシビリティテストが可能になります。 コンポーネント単位でテストができることで、1 つ 1 つアクセシビリティ的に正しいコンポーネントを作ることができ、小さい単位でアクセシビリティの改善をしていくことができるので既存プロジェクトにも導入がしやすいです。 @@ -53,7 +53,7 @@ https://github.com/YasushiKobayashi/samples/blob/master/src/next-sample/src/temp また、すべてのルールにちゃんとドキュメントがあり、今守りたいルールなのか考えながら導入していくことが可能です。 -下記のように基本的に日本語に翻訳されているルールも多いです。 +下記のように基本的には日本語訳が提供されているルールも多いです。 https://dequeuniversity.com/rules/axe/4.4/label?lang=ja @@ -65,7 +65,7 @@ https://zenn.dev/ptpadan/articles/hygen-storybook-jest ## Playwright axeでE2Eテストでもアクセシビリティテストする -`@axe-core/playwright` を使うことで、E2E テストの中でもアクセシビリティテストができます。 +`@axe-core/playwright` を使うことで、end-to-end テストの中でもアクセシビリティテストができます。 全てに対応しようとすると難しいものも多いので対応できてないルールも多いのですが、1 つのコンポーネントをテストするだけでは検出できるできないエラーを発見でき、例えばこのように h1 タグに関するエラーを出してくれます。 @@ -104,7 +104,7 @@ export const axeRunner = async (page: Page, disableRules: string[] = []) => { } ``` -Playwright のセットアップやテストの書き方については、こちらを参考にしてください Playwright が実行できていればすぐに上記のような方法でテスト可能です。。 +Playwright のセットアップやテストの書き方については、こちらを参考にしてください。Playwright が実行できていればすぐに上記のような方法でテスト可能です。 https://zenn.dev/ptpadan/articles/playwright-e2e diff --git a/articles/bun-vitest-cline-migration.md b/articles/bun-vitest-cline-migration.md index efb36395..7f02a649 100644 --- a/articles/bun-vitest-cline-migration.md +++ b/articles/bun-vitest-cline-migration.md @@ -10,7 +10,7 @@ published: true このリポジトリでは、記事とサンプルコードを 1 つのモノレポで管理し、継続的にメンテナンスしてきました。これにより、サンプルコードが現在も動作するかどうかを確認しやすくしていました。 -しかし、今後採用される可能性が低い技術のバージョンアップなどのメンテナンスには工数をかけたくないため、いくつかのサンプルコードを削除しました。また、最近よく採用している技術スタックである bun/vite などへの移行を行いました。 +しかし、今後採用される可能性が低い技術のバージョンアップなどのメンテナンスには工数をかけたくないため、いくつかのサンプルコードを削除しました。また、最近よく採用している技術スタックである bun/vite などへ移行しました。 この記事では、AI コーディングアシスタント「Cline」を使って行った bun と vitest への移行作業について紹介します。Cline は、コード変更の提案や実装を自動化してくれるツールで、今回のような移行作業を効率的に進めるのに役立ちました。 @@ -101,7 +101,7 @@ Jest から vitest への移行には以下のようなメリットがありま ## Clineを使ったvitestへの移行作業 -vitest の移行は、まず設定ファイルを手動で作成し、1つのディレクトリを手動で移行しました。具体的には、`vitest.config.ts`と`vitest-setup.tsx`を作成し、1つのプロジェクトのテストファイルを更新して動作確認を行いました。 +vitest の移行は、まず設定ファイルを手動で作成し、1 つのディレクトリを手動で移行しました。具体的には、`vitest.config.ts`と`vitest-setup.tsx`を作成し、1 つのプロジェクトのテストファイルを更新して動作確認を行いました。 テストファイルの移行では、主に以下のような変更が必要でした： - import パスの更新（`jest`→`vitest`） diff --git a/articles/eslint-update-9.md b/articles/eslint-update-9.md index 12a3e0bf..b688a6db 100644 --- a/articles/eslint-update-9.md +++ b/articles/eslint-update-9.md @@ -1,5 +1,5 @@ --- -title: ESLint 9へのアップデートとFlat Config移行の実践記録 +title: ESLint 9へのアップデートとFlat Config移行ログ emoji: "🔧" type: "tech" # tech: 技術記事 / idea: アイデア topics: ['eslint', 'typescript', 'javascript', 'linter', 'monorepo'] diff --git a/articles/hygen-storybook-jest.md b/articles/hygen-storybook-jest.md index 4b5f3fcd..dbeaaf22 100644 --- a/articles/hygen-storybook-jest.md +++ b/articles/hygen-storybook-jest.md @@ -77,7 +77,7 @@ Primary.play = async ({ canvasElement }) => { ## テンプレートをメンテナンスしていくことで、なるべく新しい書き方に追従できる -例えば、Storybook はバージョンによって推奨される書き方が変わることがあるので、テンプレートを最新の書き方にすることで最新の書き方に追従していきやすい環境を作ることができます。 +例えば、Storybook はバージョンによって推奨される書き方が変わることがあります。テンプレートを最新の書き方に更新することで、新しい書き方への追従が容易になります。 既存のコードのコピー&ペーストをベースにして作ってしまうと古い好ましくない書き方をベースにしてしまうことがありますが、テンプレートをメンテナンスしていくことで今好ましい書き方をし続けることができます。 @@ -86,7 +86,7 @@ Primary.play = async ({ canvasElement }) => { `Play function`を使用することで、シナリオテストを作成できるので、下記のようにフォームに入力・送信までテストできる Story を簡単に作成できます。 -`@storybook/jest` という addon で Storybook の中で jest のようにモックや assertion を書くこともできるので、Storybook でコンポーネントに関するテストは完結できます。 +`@storybook/jest` という addon で Storybook の中で Jest のようにモックや assertion を書くこともできるので、Storybook でコンポーネントに関するテストは完結できます。 また、簡単なテストケースであれば jsdom 上でデバッグしていくことができますが、Storybook でテストを実行しているのでブラウザ上でもテストを実行し devtool で詳しい状態を見ることができるので、複雑なシナリオのテストでもこれまでより大幅に書きやすくなりました。 @@ -155,7 +155,7 @@ https://github.com/YasushiKobayashi/samples/blob/master/src/next-sample/src/temp 参考記事はこちら。 -https://storybook.js.org/docs/react/writing-stories/play-function +https://storybook.js.org/docs/writing-stories/play-function https://storybook.js.org/addons/@storybook/addon-jest https://zenn.dev/takepepe/articles/hygen-template-generator https://zenn.dev/azukiazusa/articles/df307292037265 diff --git a/articles/jest-same-test-file.md b/articles/jest-same-test-file.md index 3f894b56..b3312e76 100644 --- a/articles/jest-same-test-file.md +++ b/articles/jest-same-test-file.md @@ -30,7 +30,7 @@ https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=37728aa5 - テスト用に新たなファイルを作成することなく、すぐにテストを書き始めることができる - 実装とユニットテストの距離が近いため、コードの理解がしやすい -のようなメリットがあり、この書き方を他の言語でもしてみたいなと思ったので、jest でできるかを試してみます。 +のようなメリットがあり、この書き方を他の言語でもしてみたいなと思ったので、Jest でできるかを試してみます。 結論としては、`jest.config` を頑張り、テストコードの書き方を工夫することできました。 @@ -79,7 +79,7 @@ jest.testRegex = targets.concat([jest.testRegex]) この書き方でテストを書けることはわかりましたが、`import`の仕方によっては、proudction コードにも影響がでてしまいそうなので、影響がないか rollup が生成するコードで確認をしてみます。 rollup でビルドしてみたコードを確認すると、下記のコードが生成されています。 -jest の`describe` が残ってしまっているため、消さないと他で import した際にエラーとなります。 +Jest の`describe` が残ってしまっているため、消さないと他で import した際にエラーとなります。 @@ -209,7 +209,7 @@ if (process.env.NODE_ENV === 'test') { \* 2022/4/20 追記 -\* jest か testing-library のアップデートかどれが原因なのか、調査まではできていないので、下記のエラーが出て非同期で import するのはできなくなっていました。 +\* Jest か testing-library のアップデートかどれが原因なのか、調査まではできていないので、下記のエラーが出て非同期で import するのはできなくなっていました。 ``` Cannot add a hook after tests have started running. Hooks must be defined synchronously. @@ -225,8 +225,8 @@ rust のように、言語仕様でできる言語同様にテストを書くこ 今回サンプルコードにした内容は全てこちらの PR で作成しており、すべて動作確認可能です。 https://github.com/YasushiKobayashi/samples/pull/59 -https://github.com/YasushiKobayashi/samples/tree/master/src/jest-same-example-rollup -https://github.com/YasushiKobayashi/samples/tree/master/src/jest-same-example-next +https://github.com/YasushiKobayashi/samples/tree/delete-rollup/src/jest-same-example-rollup +https://github.com/YasushiKobayashi/samples/tree/delete-rollup/src/jest-ts-auto-mock-sample 2021/8/21 追記：jest/ts-jest を 27 系に update すると、非同期での react-test-utils の import が動かなかったです。通常の import の場合動作します。 diff --git a/articles/laravel-ecs-ec2-1instance.md b/articles/laravel-ecs-ec2-1instance.md index 4d4aed15..fc20dd79 100644 --- a/articles/laravel-ecs-ec2-1instance.md +++ b/articles/laravel-ecs-ec2-1instance.md @@ -24,7 +24,7 @@ Laravel/ec2/docker-compose の手動デプロイで動いている API サーバ - 手動デプロイをしてることによる操作ミスで、サーバーが落ちることもありました - 環境が immutable ではない - サーバー内のコンテナの vendor の状態がわからず、想定外に自動デプロイがコケていることがありました -- ec2 上の docker の volume にしか、ログの永続化がされていない +- ec2 上の Docker の volume にしか、ログの永続化がされていない - 小規模サービスのため一旦問題ないのですが、将来的には好ましくない - autoscale 構成になっていない - ロードバランサー配下にはありましたが、autoscale 構成になっていないため、サーバーが落ちた場合自動では復旧できない可能性があります @@ -203,9 +203,9 @@ resource "aws_ecs_service" "api" { また、health check で説明した ecs の動的ポートマッピングを使用するために、nginx の hostPort は 0 を指定します。 -デプロイについての詳細は後述しますが、ecr に push する際の image id は Git のコミットハッシュを使用しており、使用するべき image id が terraform 上ではわからないので local 変数を適宜更新する形に一旦しています。 +デプロイについての詳細は後述しますが、ecr に push する際の image ID は Git のコミットハッシュを使用しており、使用するべき image ID が terraform 上ではわからないので local 変数を適宜更新する形に一旦しています。 -ここでは例えば、docker image を push するときは latest も push してそれを terraform では参照するなどの対応ができそうですが、最適な管理方法はまだわかっていません。 +ここでは例えば、Docker image を push するときは latest も push してそれを terraform では参照するなどの対応ができそうですが、最適な管理方法はまだわかっていません。 ```hcl locals { @@ -282,13 +282,13 @@ https://github.com/YasushiKobayashi/samples/tree/master/tf/laravel-ecs-ec2-1inst デプロイは ecs-deploy という shell script を使用しました。 -https://github.com/silinternational/ecs-deploy +https://github.com/sil-org/ecs-deploy ecs のデプロイには様々なツールがありますが、使用するイメージを更新したいだけの最低限のデプロイには ecs deploy が適しているように思います。 `./ecs-deploy -c api --service-name api --image ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/api:${COMMIT_ID}` のように使用するイメージを上書きするだけでデプロイができます。 -構築したサービスでは、この Makefile を GitHub actions で実行しています。 +構築したサービスでは、この Makefile を GitHub Actions で実行しています。 ```bash COMMIT_ID := $(shell git log -n 1 --pretty=format:"%H") diff --git a/articles/playwright-e2e.md b/articles/playwright-e2e.md index 816a28f4..5a51e9c9 100644 --- a/articles/playwright-e2e.md +++ b/articles/playwright-e2e.md @@ -8,9 +8,9 @@ published: true ## Playwrightとは -Playwright は Microsoft が開発している E2E テスト用のフレームワークです。 +Playwright は Microsoft が開発している end-to-end テスト用のフレームワークです。 -Selenium・Cypress・TestCafe など、いくつかの E2E テストのフレームワークを使ったことがありますが、一番使いやすいフレームワークだと感じており、今後は E2E テストを導入する際は Playwright がいいと考えています。 +Selenium・Cypress・TestCafe など、いくつかの end-to-end テストのフレームワークを使ったことがありますが、一番使いやすいフレームワークだと感じており、今後は end-to-end テストを導入する際は Playwright がいいと考えています。 ## Playwrightのメリット @@ -35,7 +35,7 @@ test('test', async ({ page }) => { ### ログがこれまでのどのツールよりも分かりやすい -Playwright でテストを失敗したときは、デフォルトでテストの記録である動画と、テスト時の DOM の状態やスクリーンショット・console・ネットワーク等のログを細かく残してくてれる zip 形式のログがあります。 +Playwright でテストを失敗したときは、デフォルトでテストの記録である動画と、テスト時の DOM の状態やスクリーンショット・console・ネットワーク等のログを細かく残してくてれる ZIP 形式のログがあります。 ![](/images/playwright/trace.png) @@ -62,11 +62,11 @@ https://playwright.dev/docs/why-playwright#fast-and-reliable-execution - ログの読みやすさ - 実行時間の速さ -上記をもとに、自分はこれら３つで E2E テストを書いたことがあり、どれも Playwright の方が便利だと感じています。 +上記をもとに、自分はこれら３つで end-to-end テストを書いたことがあり、どれも Playwright の方が便利だと感じています。 ### Autify -Autify はフレームワークではありませんが、E2E テスト作成用のサービスとして使用したことがあるので、こちらも比較してみます。 +Autify はフレームワークではありませんが、end-to-end テスト作成用のサービスとして使用したことがあるので、こちらも比較してみます。 GUI で完結するテストの作る簡単さは Autify の方が圧倒的に上で、自動で UI の変更への追従もある程度あるのでテストのメンテナンスのしやすいです。 @@ -75,7 +75,7 @@ Autify にしかないのは、前回のテスト結果との画面のスクリ 実行時間は、CI で継続的に Autify を回したことがないのでそこまで意識したことがないすが、Playwight の方がおそらく圧倒的に速いです。 -そのため予算が許せて、誰でも簡単に E2E テストを作れる環境を作りたいのであれば、Autify の方が良さそうですが、CI と連携した素早くテストを実行したい場合は Playwright の方がいいかもしれません。 +そのため予算が許せて、誰でも簡単に end-to-end テストを作れる環境を作りたいのであれば、Autify の方が良さそうですが、CI と連携した素早くテストを実行したい場合は Playwright の方がいいかもしれません。 今回サンプルコードにした内容や、動作確認で使用したコードは全てこちらの PR で作成しており、すべて動作確認可能です。 diff --git a/articles/serverless-next-isr.md b/articles/serverless-next-isr.md index d9ea0519..c4d20a5b 100644 --- a/articles/serverless-next-isr.md +++ b/articles/serverless-next-isr.md @@ -31,7 +31,7 @@ Next.js は isr/ssr 用の書き方が変わるので、そこを変えるだけ S3/CF や Firebase Hosting に Next.js をデプロイして、運用するにはパスの rewrite を自作する必要があります。 -Serverless Nextjs Plugin を使えば、パス関連もまとめて面倒を見てくれるので、export したサイトを作成する場合でも Serverless Nextjs Plugin を使うとインフラ構築が楽になります。 +Serverless Next.js Plugin を使えば、パス関連もまとめて面倒を見てくれるので、export したサイトを作成する場合でも Serverless Next.js Plugin を使うとインフラ構築が楽になります。 ## ハマったポイント ### next-i18nextを使っていないのに、ビルドエラーになる @@ -55,7 +55,7 @@ https://github.com/YasushiKobayashi/samples/pull/367 `getStaticProps` の`revalidate` に設定している値で明らかにキャッシュの更新がされずにつまりました。 -下記のようにパスごとの ttl を設定することで、キャッシュを更新できるようになりました。 +下記のようにパスごとの TTL を設定することで、キャッシュを更新できるようになりました。 https://github.com/YasushiKobayashi/samples/blob/master/src/serverless-next-isr/serverless.yml#L22-L30 @@ -71,7 +71,7 @@ isr/ssr を途中で変えることはできますが、途中で変えるとあ ### キャッシュの更新に時間差が激しい -上記でキャッシュの revalidate/ttl を短くしていても、どうしてもキャッシュの更新に時間がかかってしまう場合があるので、今回作成した例では swr と併用するようにしています。長いときは 10 分くらい更新されません。 +上記でキャッシュの revalidate/TTL を短くしていても、どうしてもキャッシュの更新に時間がかかってしまう場合があるので、今回作成した例では swr と併用するようにしています。長いときは 10 分くらい更新されません。 swr を使用することで、refetch のタイミングなどを swr に任せることがより楽にデータの管理ができます。 @@ -96,9 +96,9 @@ swr を使用することで、refetch のタイミングなどを swr に任せ ## Prismicで開発しやすくするためにしたこと -Prismic の api の叩き方は、多少癖があるきもしますが、document 見ながら試すとそれほど難しい点は恐らくなかったです。 +Prismic の API の叩き方は、多少癖があるきもしますが、document 見ながら試すとそれほど難しい点は恐らくなかったです。 -api を叩くだけでは問題なさそうだったのですが、Prismic のレスポンスの型をみると any を使っており generics に対応してなかったので、継承して下記のように自分で型を作りました。 +API を叩くだけでは問題なさそうだったのですが、Prismic のレスポンスの型をみると any を使っており generics に対応してなかったので、継承して下記のように自分で型を作りました。 \* 2022/4/20 追記 @@ -196,7 +196,7 @@ export const fetchPosts = async (client: DefaultClient) => { } ``` -react でのレンダリングは`prismic-reactjs`を使うことで、html をそのままレンダリングするパターン、text だけレンダリングしたいときも簡単に対応できました。 +react でのレンダリングは`prismic-reactjs`を使うことで、HTML をそのままレンダリングするパターン、text だけレンダリングしたいときも簡単に対応できました。 ```typescript @@ -221,11 +221,11 @@ const Pages: React.VFC = ({ post }) => { 作成にあたって試したコードはこちらです。 -https://github.com/YasushiKobayashi/samples/tree/master/src/serverless-next-isr +https://github.com/YasushiKobayashi/samples/tree/delete-serverless-next-isr/src/serverless-next-isr \* 2025/03/09 追記 -Prismic/ Serverless framework の最新バージョンへの追従とバージョンアップ用の動作確認が困難なためサンプルコードの削除を行いました。 +Prismic/ Serverless framework の最新バージョンへの追従とバージョンアップ用の動作確認が困難なためサンプルコードを削除しました。 削除前のコードはこちらに tag をつけています。 https://github.com/YasushiKobayashi/samples/releases/tag/delete-serverless-next-isr diff --git a/articles/terraform-update.md b/articles/terraform-update.md index 95cd1ec4..8e74db2c 100644 --- a/articles/terraform-update.md +++ b/articles/terraform-update.md @@ -8,7 +8,7 @@ published: true Terraform を 0.11 系で動いていたものを、一気に Terraform1 系まで一気に update しました。 -まだ 0.11 系を使っている人はあまりいないと思うので、この記事のニーズがあるかわかりませんが、ハマりどころをまとめていきます。 +まだ 0.11 系を使っている人はあまりいないと考えられるので、この記事のニーズがあるかわかりませんが、ハマりどころをまとめていきます。 ## 古いバージョンが動かないので、上げないと身動きがとれなくなった @@ -24,7 +24,7 @@ Terraform を 0.11 系で動いていたものを、一気に Terraform1 系ま > This guide focuses on changes from v0.13 to v0.14. Terraform supports upgrade tools and features only for one major release upgrade at a time, so if you are currently using a version of Terraform prior to v0.13 please upgrade through the latest minor releases of all of the intermediate versions first, reviewing the previous upgrade guides for any considerations that may be relevant to you. -https://www.terraform.io/upgrade-guides/0-14.html +https://developer.hashicorp.com/terraform/language/upgrade-guides/0-14 上記のように、0.14 系より新しいバージョンの Terraform を使用するためには、0.13 系を経由して apply をして state の状態をバージョンアップできるようにする必要があります。 diff --git a/articles/terrform-state-migration.md b/articles/terrform-state-migration.md index 69ac0c1f..0fad1e30 100644 --- a/articles/terrform-state-migration.md +++ b/articles/terrform-state-migration.md @@ -10,7 +10,7 @@ Terraform で aws のリソースを管理し state は S3 で管理している ## Terraformのstateが他のものが引き継がれてしまっている -state や provider の設定などは、基本的にどのディレクトリでも一緒になるので大体はファイルごとコピーを行い、state のキーだけを変更して`terraform init`を行っていました。 +state や provider の設定などは、基本的にどのディレクトリでも一緒になるので大体はファイルごとコピーし、state のキーだけを変更して`terraform init`を行っていました。 今回は、state のキーの変更を忘れて、 `terraform init` を先に行ってしまいました。 diff --git a/bun.lockb b/bun.lockb index 8fe61192..ed5adc94 100755 Binary files a/bun.lockb and b/bun.lockb differ diff --git a/package.json b/package.json index d9f87318..4ab77e40 100644 --- a/package.json +++ b/package.json @@ -75,14 +75,25 @@ "path": "^0.12.7", "playwright": "^1.27.1", "prettier": "^3.0.0", - "textlint": "^14.0.0", - "textlint-rule-ja-no-mixed-period": "^3.0.1", + "textlint": "^14.8.4", + "textlint-rule-abbr-within-parentheses": "^1.0.2", + "textlint-rule-common-misspellings": "^1.0.1", + "textlint-rule-ja-no-mixed-period": "^3.0.2", + "textlint-rule-ja-no-redundant-expression": "^4.0.1", + "textlint-rule-ja-no-successive-word": "^2.0.1", + "textlint-rule-ja-unnatural-alphabet": "^2.0.1", + "textlint-rule-max-kanji-continuous-len": "^1.1.1", "textlint-rule-max-ten": "^5.0.0", - "textlint-rule-no-mix-dearu-desumasu": "^6.0.0", - "textlint-rule-preset-ja-spacing": "^2.3.0", - "textlint-rule-preset-ja-technical-writing": "^12.0.0", - "textlint-rule-prh": "^6.0.0", + "textlint-rule-no-dead-link": "^6.0.1", + "textlint-rule-no-doubled-joshi": "^5.1.1", + "textlint-rule-no-empty-section": "^1.1.0", + "textlint-rule-no-mix-dearu-desumasu": "^6.0.4", + "textlint-rule-no-todo": "^2.0.1", + "textlint-rule-preset-ja-spacing": "^2.4.3", + "textlint-rule-preset-ja-technical-writing": "^12.0.2", + "textlint-rule-prh": "^6.1.0", "textlint-rule-spellcheck-tech-word": "^5.0.0", + "textlint-rule-terminology": "^5.2.15", "tsconfig-paths-webpack-plugin": "^4.0.0", "typescript": "^5.8.2", "typescript-eslint": "^8.43.0",