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.