Replace the unmaintained OCaml Flow parser dependency

まず、既存の Flow parser 統合と、compiler/js_parser 配下に以前 vendored されたソースを読みます。構文検証、エラー位置、regexp 検証、関数のアリティ、リテラルの分類、コメント処理を対象とする、範囲を絞った parser インターフェースを定義し、一覧にあるケースのテストを追加します。完了条件は、両方の parser 実装を同じコーパスに対して比較でき、互換性が十分であれば依存関係を削除できることです。

Problem

ReScript depends on the unmaintained OCaml implementation of flow_parser to validate and classify JavaScript in %raw expressions.

Our fork supports ppxlib 0.36, which requires OCaml < 5.4. This blocks upgrades to OCaml 5.4 and 5.5. Updating the fork for each ppxlib release would only postpone the problem.

ReScript currently depends directly on Flow AST and parser types, although it only needs syntax validation, error locations, regexp validation, and classification of literals, functions and comment-only statements.

Possible solutions

1. Vendor the Flow parser

ReScript previously vendored these sources under compiler/js_parser.

We could restore the currently used parser sources and maintain them inside the repository. Ideally, we would commit the PPX-generated OCaml code so the parser no longer depends on ppxlib.

This is the lowest-risk solution and can preserve the existing direct Flow AST integration. However, it leaves ReScript responsible for roughly 33,000 lines of parser code whose JavaScript syntax support will no longer receive upstream updates.

2. Move to js_of_ocaml’s JavaScript parser

js_of_ocaml-compiler's Parse_js API provides maintained OCaml functions for parsing JavaScript expressions and programs.

For a safe migration, we should first introduce a small ReScript-owned parser interface backed by the existing Flow parser. This interface would expose only the operations ReScript needs and remove direct uses of Flow_ast, Parser_flow, Loc, and Parse_error from the rest of the compiler.

We should add focused tests for parsing, error locations, regexp validation, function arity, literal classification, leading comments and comment-only programs. The js_of_ocaml implementation could then be tested against the same corpus before switching.

js_of_ocaml maintains its parser to read JavaScript runtimes and user-provided stubs before linking and optimizing them with generated JavaScript. Its primary goal is therefore not to be a universal parser supporting every new TC39 feature immediately. Its syntax coverage, diagnostics, comment handling and classifications must be compared with the current Flow implementation.

A migration could be split into two independent changes:

1. Introduce the internal parser abstraction backed by Flow Parser and strengthen test coverage.
2. Implement the abstraction using js_of_ocaml, compare both implementations, and remove flow_parser if compatibility is sufficient.

Decision

• Vendoring is the quickest and least disruptive solution, but makes ReScript the permanent owner of an unmaintained parser.
• Moving to js_of_ocaml requires more migration work, but offers a maintained long-term dependency with much less parser-specific coupling.