parser-tsをeffect版にしたもので置き換える

[ncaq]

Effect-TSベース 汎用パーサコンビネータ ライブラリ調査レポート

TL;DR

• 結論: Effectエコシステムには「parser-tsのEffect版fork」に相当する先行実装は存在しません。 npm・GitHub・Effect-TS公式org (23リポジトリ)・コミュニティを網羅的に調査した結果、effect パッケージを実際の依存として持ち、Effect型 (Effect, Either, Option) を主要APIに露出させた汎用パーサコンビネータライブラリは 1件も発見されませんでした。
• 最有力候補に見えた saiashirwad/parserator (51★, WIP, MIT, v0.1.41) は GitHubトピックに effect タグを付けているにもかかわらず、package.json の dependencies フィールドが空で effect パッケージへの依存はなく、Either は src/either.ts 内の独自実装 (API shapeのみEffect/fp-ts互換、ランタイム相互運用不可)。したがって厳密にはユーザ要件から除外されます。
• 判断: forkすべき (再発明にはならない)。 Effect-nativeな汎用パーサコンビネータは未開拓領域です。さらに gcanti/parser-ts 本体も v0.7.0 が 2023年4月26日 で更新が止まっており (npmjs.com/package/parser-ts に "Published 3 years ago" と表示)、fp-tsのEffect-TSへの公式統合 (2023年2月18日、Michael Arnaldi が dev.to 記事 "A bright future for Effect" で発表: "the fp-ts project is officially merging with the Effect-TS ecosystem, and... Giulio Canti, is being welcomed into the Effect organization") 以降もEffect環境への移植は誰も着手していません。

Key Findings

1. parser-ts のEffect版fork → 存在しない

GitHubで gcanti/parser-ts のforkは19件ありますが、すべてfp-tsベースのままで、Effect版移植リポジトリはありません。本家も v0.7.0 (2023-04-26) 以降メジャー更新なし。

2. Effect-TS 公式エコシステム → パーサコンビネータパッケージなし

Effect-TS GitHub organization (effect, effect-smol, language-service, cli, schema, platform, sql系, ai, build-utils 等23リポジトリ) と effect.website のパッケージ一覧 (@effect/cli, @effect/platform, @effect/sql, @effect/ai, @effect/schema 等) を確認しましたが、汎用パーサコンビネータは含まれません。@effect/cli 内部に CLI引数パーサは存在しますがドメイン専用、@effect/schema は型変換用であり、いずれも除外対象。

3. @fp-ts/parser → 過去に公開された形跡なし

fp-ts → Effect-TS 統合の経緯で @fp-ts/core, @fp-ts/schema, @fp-ts/data などの実験的パッケージは存在しましたが、@fp-ts/parser という名前のパッケージはnpm registryで発見できませんでした。

4. サードパーティ候補の精査

候補	スター	最終更新	Effect依存	汎用性	結論
saiashirwad/parserator	51	2026-01-13	❌ なし (独自Either)	◎ (seq/alt/many/sepBy/commit/atomic)	除外 (Effect非依存)
gcanti/parser-ts	197	2023-04-26	❌ (fp-ts)	◎	ユーザ認識済み・除外
microsoft/ts-parsec	active	active	❌	◎	Effect非依存
francisrstokes/arcsecond	576	2024-02-15	❌	◎	Effect非依存
GregRos/parjs	315	2025-11-05	❌	◎	Effect非依存
thi-ng/umbrella (@thi.ng/parse)	3.8k	active	❌	◎	Effect非依存
その他 (peberminta 36★, sigma 28★, terrario 33★, parsea 等)	10-36	mixed	❌	various	Effect非依存

5. 日本語コミュニティ

Zenn・QiitaでEffect-TSによるパーサコンビネータ実装記事は確認できませんでした。mizchi氏のZenn記事はGenerator/AsyncGeneratorベースの独自エフェクトシステム自作で、パーサ用途ではありません。

Details

最有力候補だった saiashirwad/parserator の精査結果

リポジトリ: https://github.com/saiashirwad/parserator npm: parserator@0.1.41, MIT, 2026年1月頃公開, dependents: 0 著者: Sai (Bangalore, @texoport__) コミット数: 359コミット / 41タグ (活発に開発中、最終コミット 2026-01-13)

Effect依存の真偽 — 依存していない

GitHubトピックに effect タグが付与され、サンプルコードに Either.isLeft(result.result) のような Effect ライクなAPIが出てくるため一見Effect依存に見えますが、実際には effect パッケージへの依存はありません:

• package.json の dependencies フィールドは存在せず、README で "Zero dependencies" を明言
• peerDependencies は typescript: ^5.0.0 のみ
• Either は src/either.ts 内の独自実装 (Left<L,R> / Right<R,L> のタグユニオン、_tag プロパティで判別)
• ソースコード内で from "effect" のimportは存在しない (DeepWiki解析により確認)

API shapeは Effect/fp-ts 互換に見えますが、ランタイムで effect の Either モジュールと相互運用はできません。

機能カバレッジ (parser-ts比較)

parserator が提供する主要コンビネータ:

• ✅ char, string, regex, digit, alphabet
• ✅ many, many1, many0, optional, or (= alt), sepBy, between, takeUntil, notChar, eof
• ✅ Generatorベースのモナディック構文 (parser(function* () { yield* ... }))
• ✅ .map, .flatMap, .expect, .commit (バックトラック制御), .atomic (all-or-nothing)
• ✅ Levenshtein距離によるタイポ提案、ソースコードフレーム付きエラー
• ⚠️ chainRec (parser-tsのスタックセーフ再帰) は確認できず
• ⚠️ トークン列入力 (parser-ts の Parser<I, A> の I 抽象化) は string 中心

機能的にはparser-tsに迫りますが、Effect統合 (Effect.Effect で包む、Layer/Context依存注入、Streamからの逐次パース等) は存在しません。

parser-ts の現状とユーザ需要

• npm週間ダウンロード: 1,898 (npmjs.com/package/parser-ts 2026年5月時点表示)
• v0.7.0 公開: 2023年4月26日 (npmjs.com に "Published 3 years ago" 表示)
• 23パッケージが依存
• 既知issue: 長文字列での Maximum call stack size exceeded (Issue build(deps): lock file maintenance #45) — chainRec の最適化不足を示唆
• 注目すべき経緯: fp-ts は2023年2月18日にEffect-TSへの統合が正式発表され、Giulio Canti自身がEffect organizationに参加。これは parser-ts の後継が Effect 上で再構築される潜在的機運を示唆しますが、3年経った現在も公式の Effect版 parser-ts は公開されていません。

Effect Discord / コミュニティでの言及

Effect公式Discord内部ログへのAPIアクセスは不可ですが、Effect関連の主要公開ソース (effect.website blog, tweag.io, dev.to のEffect紹介記事群, Dimitrios Lytras のブログ等) を確認した範囲では、サードパーティ製パーサコンビネータの言及はありませんでした。Effectコミュニティの主要関心はSchema・HTTP・SQL・AIに向いており、パーサコンビネータは明確に未充足のニッチです。

Recommendations

段階的アプローチ

Stage 1 — 即座に着手 (強く推奨) parser-ts の Effect 版 fork を自作することに強い正当性があります。理由:

1. 同等品が存在しないことを本調査で確認
2. parser-ts 本家が3年間メジャー更新停止
3. fp-ts → Effect-TS 統合 (2023-02-18) により Effect 上の関数型パーサ需要は今後増加が見込まれる
4. parser-ts のAPI設計は成熟しており、Effect への移植は機械的作業の比重が高い

Stage 2 — 移植戦略

• Parser<I, A> の戻り値 ParseResult<I, A> を Effect.Effect<ParseSuccess<I, A>, ParseError<I>, R> に置換 (もしくは Either<ParseError, ParseSuccess> を維持してEffectの Either モジュールを使用)
• chainRec を Effect.iterate ベースで再実装 (parser-ts Issue build(deps): lock file maintenance #45 のスタックオーバーフロー解消)
• Stream<I> 入力対応で逐次パース可能化 (effect の Stream モジュールと統合)
• Context.Tag / Layer で字句解析器・エラーフォーマッタを依存注入可能に
• 既存parser-ts利用者向けに薄い互換レイヤを提供

Stage 3 — 公開戦略

• パッケージ名候補: effect-parser, parser-effect, @effect-contrib/parser (parserator は既存利用)
• Effect-TS本家の Discussions で @effect/parser のRFCとして提案を打診
• 機能セットは parser-ts と parserator の和集合 (seq/alt/many/sepBy/chainRec/commit/atomic/lookAhead/sat/regex) を最低ライン

Forkを再検討すべき条件 (ベンチマーク)

以下の状況になれば判断を見直してください:

• ❗ Effect-TS org に @effect/parser のRFC・Issue・PRが立つ
• ❗ saiashirwad/parserator が effect への依存を追加してEffect-native化する (GitHubトピックに effect が付いているので可能性あり、Issueで方針確認推奨)
• ❗ Giulio Canti が parser-ts v1.0 または @effect/parser 公式版を発表する

Caveats

• parseratorのEffect統合計画: 著者 saiashirwad はGitHubトピックに effect を付けているため、将来的にEffect依存に移行する可能性があります。本調査開始前に同氏のIssue (https://github.com/saiashirwad/parserator/issues) でEffect統合の方針を確認することを強く推奨します。
• npm週間ダウンロード数の取得失敗: parserator のnpmjs.comページが直接フェッチできず、parserator の週間DL数は取得できませんでした。dependents: 0 と "WIP" 表明から実利用は限定的と推定。
• Discord内部議論の不可視性: Effect公式Discord内で @effect/parser 構想が議論されていてもログがWeb公開されていない可能性があります。Discordに参加し #feedback や #contrib チャンネルで直接確認することを推奨します。
• GitHubコードサーチの限界: 本調査はトピックタグ・キーワード検索を中心としており、effect を import しているがリポジトリ説明にパーサコンビネータと書いていないニッチな個人実装を見落としている可能性は残ります。ただし汎用ライブラリとして実用に値する規模ならスター・ダウンロードで露出するはずで、現実的影響は小さいと判断します。
• 判断の前提: 本結論は「ユーザがEffect-TS環境で型安全な汎用パーサコンビネータを必要としている」前提です。もし @effect/schema の Schema.transformOrFail で要件が満たせる場合 (構造化された入力からデータ抽出する程度) は、新規実装より既存資産活用を検討してください。