effect-v4 について
Effect v4は、Composio CLIと関連パッケージでEffect v4を扱うためのスキルです。移行後のソースに基づき、API、CLIのパターン、テスト、アップグレードを案内し、固定バージョンで例を検証します。
主な機能
- 01Effect v4の基本パターン
- 02CLIサーフェスのリファレンス
- 03型付きエラーとSchema
- 04TestClockによるテスト
- 05バージョン更新の手順
- 06コンパイル検証済みのコード例
活用シーン
- 01EffectベースのCLIコードの保守
- 02Effect v4へのコード移行
- 03Effectワークフローのテスト作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ composiohq/ composio --skill effect-v4インストール後、Claude Code で/effect-v4を入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
versions.jsonreferences/cli-surface.mdcore-patterns.mdupgrade-workflow.mdscripts/check-examples.mjs詳細
Effect v4
CLI、@composio/cli-keyring、@composio/json-schema-to-effect-schema は Effect v4 で動作します。以下の説明はすべて、v3 の記憶ではなく、移行済みのソースに基づいています。
正確なバージョンの組み合わせ
effect、@effect/platform-bun、@effect/vitest はすべて、同一の正確な 4.0.3 に固定されています。^、@next、パッケージ間で異なるバージョンは使いません。依存関係としての @effect/cli と @effect/platform はなくなり、それらの機能は effect と effect/* に統合されています。完全な組み合わせ(typescript、vitest も含む)については、versions.json を参照してください。
次に読む資料
- references/core-patterns.md — サービス、レイヤー、型付きエラー、Schema、
Effect.genとEffect.fnの使い分け、isSomeを使った三項演算子の代わりとなるOptionコンビネーター、it.liveの代わりにTestClockでテスト内の時間を進める方法(fork、adjust してファイバーが終了するまで待ち、join)、および v3→v4 の名称変更表(古いパターンを見分けるための参考資料であることを明記しています)。 - references/cli-surface.md —
effect/cli:Command、Flag、Argument、GlobalFlag、CliConfig、カスタムのCliOutput.Formatter、およびランナーの二重出力ルール。 - references/upgrade-workflow.md — 新しいリリースに更新する手順。
これらの資料にあるコード抜粋は、実際に現在コンパイルできるリポジトリのファイルから短く引用したものです(各抜粋にパスが記載されています)。単独で動作する例ではありません。コンパイル検証済みの正しい情報源は、常に引用元のファイル自体です。ファイルと資料の内容が異なる場合は、ファイルを優先し、資料を修正してください。
必須事項
- エフェクト値には
Effect.gen(function* () {...})を使います。名前付きのモジュール定数もこの形式が基本です。パラメーター付きヘルパーには(params) => Effect.gen(...)を使います。Effect.fn(...)は、エフェクトにスタックフレームの注釈が付く関数形式です(省略可能な名前文字列を指定すると、呼び出しごとにトレーススパンが追加されます)。エラー報告で追跡可能にするサービスメンバーやコンビネーターのコールバックに適しています。どの形式も、実行のたびに本体を再実行します。core-patterns の「Effect.genvsEffect.fn」を参照してください。 - サービスは
Context.Serviceで定義し、Layer.succeed/Layer.effect/Layer.provideで構築したstatic readonly Default/layerレイヤーを明示します。v4 はレイヤーを自動生成しません。 - 想定される失敗は
Schema.TaggedError(Schema フィールドが不要な場合は通常のData.TaggedError)でモデル化し、Effect.catchTag/catchTags/Matchで回復します。_tag文字列を手動で比較してはいけません。 - 失敗する可能性のある Promise は
Effect.tryPromise({ try, catch })でラップします。Effect.promiseは拒否を defect に変換します。Effect のワークフロー内ではasync/awaitやtry/catchを使いません。ts/packages/cli/srcでは ESLint がこれらを禁止しています。 - 覚えている v3 のパッケージ名や API はすべて、
ts/vendor/effect(読み取り専用のソース確認先です。編集やインポートは禁止)およびインストール済みの[email protected]の型定義と照合するまでは誤りとして扱います。ソースが公開済みパッケージより先行している場合があります。互換性の判定基準はコンパイラーです。
検証
pnpm typecheck
pnpm --filter @composio/cli test
このスキルまたはその説明を編集した後は pnpm validate:agent-skills と pnpm validate:skill-routing を実行し、このスキル内および typescript-testing/references/effect-v4-cli.md 内の TypeScript ブロックを、固定されたパッケージに対してコンパイルしてください。
node .agents/skills/effect-v4/scripts/check-examples.mjs
解決できないインポートを含むリポジトリファイルを引用するブロックには、フェンス情報文字列として no-check を指定します。