React Hook Form Resolversで検証ライブラリを差し替える

フォーム状態とスキーマを分離する

react-hook-form/resolvers の README はプロジェクトを「 Validation resolvers: Yup, Zod, Superstruct, Joi, Vest, Class Validator, io-ts, Nope, computed-types, typanion, Ajv, TypeBox, ArkType, Valibot, effect-ts, VineJS and Standard Schema」と説明しています。ここではリポジトリで確認できる事実だけを整理します。star 数やバッジは注目度の手掛かりであり、品質の証明ではありません。「React Hook Form Resolvers」には次の説明があります。This function allows you to use any external validation library such as Yup, Zod, Joi, Vest, Ajv and many others. The goal is to make sure you can directly integrate whichever validation library you prefer.。これは範囲の説明であり、本番検証の結果ではありません。

@hookform/resolversの役割は、フォーム状態を管理するReact Hook Formと、外部の検証ライブラリの間に変換層を置くことです。READMEはYup、Zod、Joi、Vest、Ajvなど多数のresolverを列挙し、ライブラリを使わない場合は独自ロジックも書けると説明します。resolverを変えてもスキーマの意味が自動で揃うわけではありません。

resolver比較表が示す型の差

README の「Links」にある内容から、用途が合うかを先に判断できます。React-hook-form validation resolver documentation。目的が違うなら、人気だけで採用する理由にはなりません。プロジェクト名やコマンドは原文のまま残し、一次資料へ戻って用語を確認できるようにしています。 README には次の確認可能な項目もあります。React-hook-form validation resolver documentation。初回テストの材料にはなりますが、実際の環境での確認を省略する理由にはなりません。

比較表では、スキーマから値の型を推論できるかと、criteriaModeのfirstErrorまたはallへの対応が別々に示されています。Zod、Yup、Valibot、Standard Schemaなどで型推論が可能とされる一方、すべてのアダプターがallを同じ形で返すわけではありません。画面に出すエラー数を仕様として決めてから選びます。

InputとOutputをTypeScriptで分ける

動作の説明は「Install」など複数の箇所に分かれています。確認できる情報は次の通りです。npm install @hookform/resolvers # npm yarn add @hookform/resolvers # yarn pnpm install @hookform/resolvers # pnpm bun install @hookform/resolvers # bun。書かれていない構成、性能、セキュリティを推測で補いません。導入時はディレクトリ、設定ファイル、release 履歴を確認してください。

Zodの例ではz.objectでidを数値にし、zodResolver(schema)をuseFormへ渡します。useForm<Input, Context, Output>()を使い、z.input<typeof schema>とz.output<typeof schema>を分けて指定する方法もREADMEにあります。変換やcoerceを含むスキーマでは、入力フォームの型と送信後の型を同一視しないことが検証の要点です。

criteriaModeが変えるエラー集合

初回導入は README の入口から始めます。確認できるコマンドは次の通りです。

READMEには直接コピーできる導入コマンドがありません。

実行可能なコマンドがない場合は手順を作らず、「Install」で依存関係、待受ポート、初回設定を確認します。

インストールはnpm install @hookform/resolversと、選んだ検証ライブラリを別に追加します。npm、Yarn、pnpm、Bunの入口が示されていますが、パッケージマネージャーを混在させる手順ではありません。lockfile、React、react-hook-form、resolver、検証ライブラリの組み合わせを一つのブランチで固定します。

インストールと個別アダプター

日常運用は公式文書の範囲に限ります。「Install」には| resolver | Infer values from schema | criteriaMode | | -------------------- | -------------------------------- | ----------------------------------------------------------------------- | | AJV | | firstError \| all | | ata-validator |とあります。設定、環境変数、権限、データ保存先は明記されたものだけを扱います。未記載の既定値は隔離環境で確認し、戻せる設定を保存してください。 同じ資料にはReact-hook-form validation resolver documentationともあります。

resolver比較表にあるは、そのライブラリの値を型として扱えることを示す目安であり、実行時のエラーメッセージや非同期処理の挙動まで同じという意味ではありません。必要な項目がfirstErrorだけかallか、変換後の値を送信するか、配列エラーをどう表示するかを先に書き出します。

複雑なスキーマで境界を測る

制約も確認が必要です。現在の資料からは、react-hook-form/resolvers の互換表、性能基準、サービス保証、長期サポートを確認できません。README の記載は「Most of the resolvers can infer the output type from the schema. See comparison table for more details.」です。不明点は採用記録の検証項目として残し、断定に変えないでください。

標準スキーマ対応は、採用候補を一つの実装規約へ寄せる入口になります。ただしREADMEは各ライブラリの全機能を比較していません。複数フィールドの相関条件、空文字、数値変換、非同期検査、サーバー再検証を含む入力を用意し、resolverの戻り値とformState.errorsを直接確認します。

採用前に検証結果を固定する

ライセンスはメタデータと LICENSE に基づき、SPDX は MIT です。再配布や改変の条件を確認する情報であり、安全審査の代わりではありません。認証情報、公開範囲、ログ、依存ライブラリの扱いは別途確認が必要です。

確認手順は、同じuseFormにZodともう一つのresolverを順番に接続し、空値、型違い、相関エラー、複数エラーを送信することです。criteriaModeをfirstErrorとallで切り替え、handleSubmitへ渡るOutput、errorsのpath、npm lockfileの差分を保存します。型チェックとブラウザ実行が一致して初めて、交換可能な範囲を判断できます。

実装の差を確認するには、フォームコンポーネントを一つに固定し、resolverだけを置き換えます。schemaの入力値、成功時のdata、失敗時のerrorsを保存し、criteriaModeと型推論の組み合わせを表にします。READMEの比較表は選択の入口であり、実際の画面契約はこのテストで決めるべきです。

編集部の結論

React Hook Form Resolversで検証ライブラリを差し替えるは、READMEに示された構成を自分の環境で検証できる開発者やチームに向きます。文書だけで性能、互換性、運用上の安全性まで保証されたと考える利用者には向きません。導入前に、この記事で挙げた固有のコマンドと入力を小さな隔離環境で実行し、ログ、出力、失敗時の状態を記録してから対象範囲を広げてください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes