Fix CI: cap js_of_ocaml < 6.4, pin dune < 3.24, add lwt_ppx#268
Merged
Conversation
dune 3.24 changed dune-variable paths to a leading-"./" form (ocaml/dune#15156). wasm_of_ocaml-compiler 6.4.0 (pulled in by eliom) derives its wat-module names from those paths, so the "module:path" lines it feeds to wasmoo_link_wasm become malformed and the build fails with "The runtime contains unknown imports", breaking both the Build and Documentation workflows at the `opam install . --deps-only` step. Pin dune to 3.23.1 before the dependency install until js_of_ocaml 6.4.1 (which fixes this upstream, ocsigen/js_of_ocaml#2371) reaches the opam repository, at which point the pin can be dropped. A bare `dune<3.24` constraint on `opam install --deps-only` does not bind the transitive version, so an explicit pin is required. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
db669bf to
5dd93db
Compare
src/widgets/dune uses lwt_ppx as a preprocessor (both the server and client libraries), but it was never declared in the package depends -- it used to be pulled in transitively. With the current eliom that transitive path is gone, so the build fails with `Error: Library "lwt_ppx" not found` at `dune build @install`. Declare lwt_ppx explicitly and regenerate ocsigen-toolkit.opam. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
js_of_ocaml 6.4.0 changed the Dom_html API (inputElement), which breaks
the build of src/widgets/ot_picture_uploader.eliom
("The value input has type Dom_html.inputElement Js.t ..."). Rather than
depend on the not-yet-released source fix (#267), cap js_of_ocaml below
6.4 so CI stays on the 6.3.x line until we adopt 6.4 deliberately.
The dune < 3.24 pin is still required: the 6.3.x wasm_of_ocaml runtime
derives its wat-module names from dune-variable paths the same way 6.4.0
does, so it also breaks under dune 3.24's leading-"./" path form.
Also replace the hardcoded binaryen download in the Build workflow with
the Aandreba/setup-binaryen action already used by the docs workflow (and
by js_of_ocaml's own CI), so binaryen is provisioned on macOS too and the
version is no longer pinned by hand.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hhugo
added a commit
to hhugo/ocsigen-toolkit
that referenced
this pull request
Jul 2, 2026
The cap was a stopgap in ocsigen#268 to keep CI off js_of_ocaml 6.4.0 while the Ot_picture_uploader source was incompatible with the new Dom_html inputElement API. This PR fixes that incompatibility, so js_of_ocaml 6.4 can be used again. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hhugo
added a commit
to hhugo/ocsigen-toolkit
that referenced
this pull request
Jul 2, 2026
The Ot_picture_uploader fix in this PR relies on the js_of_ocaml 6.4.0 Dom_html inputElement API, so the toolkit no longer builds against older js_of_ocaml. Bump the lower bound to 6.4.0 (this also drops the temporary < 6.4 cap ocsigen#268 added while the source was incompatible). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hhugo
added a commit
that referenced
this pull request
Jul 2, 2026
* Ot_picture_uploader: fix build with js_of_ocaml >= 6.4.0
Since js_of_ocaml 6.4.0, `Dom_html.inputElement`'s `files` field is
typed `File.fileList Js.t Js.opt` (nullable) instead of a plain
`File.fileList Js.t`. `process_file` and `bind_input` called `##item`
directly on `input##.files` without unwrapping the `Js.opt`, which no
longer type-checks:
Error: This expression has type File.fileList Js.t Js.opt
but an expression was expected of type < .. > Js.t
Unwrap the nullable `files` with an extra `Js.Opt.case` before calling
`item`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Require js_of_ocaml >= 6.4.0
The Ot_picture_uploader fix in this PR relies on the js_of_ocaml 6.4.0
Dom_html inputElement API, so the toolkit no longer builds against
older js_of_ocaml. Bump the lower bound to 6.4.0 (this also drops the
temporary < 6.4 cap #268 added while the source was incompatible).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI on
masteris red. Three independent problems, each surfacing only once the previous one was cleared:1.
wasm_of_ocamlruntime fails to build under dune 3.24opam install . --deps-onlybuildswasm_of_ocaml-compiler(pulled in transitively byeliom) and it fails withThe runtime contains unknown imports.Cause: dune 3.24 changed dune-variable paths to a leading-
./form (ocaml/dune#15156). The wasm runtime derives its wat-module names from those paths (Filename.chop_suffix argv ".wat"), so themodule:pathlines fed towasmoo_link_wasmbecome./array:./array.watand linking reports every runtime primitive as an unknown import. Fixed upstream only in js_of_ocaml 6.4.1 (ocsigen/js_of_ocaml#2371), which isn't in the opam repository yet — and the 6.3.x line (which we pin to, see below) has the same bug. Fix: pinduneto 3.23.1 for the dependency install.2.
Library "lwt_ppx" not foundsrc/widgets/duneuseslwt_ppxas a preprocessor (server and client), but it was never declared in the package depends — it used to come in transitively. Fix: declarelwt_ppxexplicitly (regeneratedocsigen-toolkit.opam).3. js_of_ocaml 6.4.0
Dom_htmlAPI change breaks the sourcesrc/widgets/ot_picture_uploader.eliomfails to type-check against the newinputElementAPI. The source fix is #267; rather than depend on it, capjs_of_ocaml < 6.4so CI stays on the last-good 6.3.x line until 6.4 is adopted deliberately.Also
Aandreba/setup-binaryenaction already used by the docs workflow (and js_of_ocaml's own CI), provisioning binaryen on macOS too.All three Build matrix jobs (ubuntu 5.3 / 5.4, macos 5.4) are green. The Documentation workflow only runs on push to
master, so it can't be exercised from this PR, but it receives the same dune pin,lwt_ppx, and jsoo-cap fixes.🤖 Generated with Claude Code