Replace the unmaintained OCaml Flow parser dependency

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.

Inizia leggendo l’integrazione esistente del parser Flow e le sorgenti precedentemente vendorizzate in compiler/js_parser. Definisci l’interfaccia mirata del parser per la validazione della sintassi, le posizioni degli errori, la validazione delle regexp, l’arità delle funzioni, la classificazione dei literal e la gestione dei commenti, quindi aggiungi test per i casi elencati. Il lavoro è completo quando entrambe le implementazioni del parser possono essere confrontate con lo stesso corpus e la dipendenza può essere rimossa se la compatibilità è sufficiente.