Ot_picture_uploader: fix build with js_of_ocaml >= 6.4.0#267
Merged
Conversation
hhugo
added a commit
to hhugo/opam-repository
that referenced
this pull request
Jul 2, 2026
ocsigen-toolkit 4.2.0 does not build against js_of_ocaml >= 6.4.0: since 6.4.0, Dom_html.inputElement##.files is typed File.fileList Js.t Js.opt (nullable) and Ot_picture_uploader calls ##item on it without unwrapping the opt. Fixed upstream in ocsigen/ocsigen-toolkit#267; cap the existing release in the meantime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hhugo
added a commit
that referenced
this pull request
Jul 2, 2026
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
that referenced
this pull request
Jul 2, 2026
* ci: pin dune < 3.24 to fix wasm_of_ocaml build 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> * Add missing lwt_ppx dependency 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> * Cap js_of_ocaml < 6.4 and use setup-binaryen action 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> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
hhugo
force-pushed
the
fix-inputElement-files-opt
branch
from
e4d8cb0 to
bbc3e3d
Compare
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
force-pushed
the
fix-inputElement-files-opt
branch
from
7dc291b to
3125321
Compare
Merged
mseri
pushed a commit
to paurkedal/opam-repository
that referenced
this pull request
Jul 3, 2026
ocsigen-toolkit 4.2.0 does not build against js_of_ocaml >= 6.4.0: since 6.4.0, Dom_html.inputElement##.files is typed File.fileList Js.t Js.opt (nullable) and Ot_picture_uploader calls ##item on it without unwrapping the opt. Fixed upstream in ocsigen/ocsigen-toolkit#267; cap the existing release in the meantime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Kakadu
pushed a commit
to Kakadu/opam-repository
that referenced
this pull request
Jul 4, 2026
ocsigen-toolkit 4.2.0 does not build against js_of_ocaml >= 6.4.0: since 6.4.0, Dom_html.inputElement##.files is typed File.fileList Js.t Js.opt (nullable) and Ot_picture_uploader calls ##item on it without unwrapping the opt. Fixed upstream in ocsigen/ocsigen-toolkit#267; cap the existing release in the meantime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Since js_of_ocaml 6.4.0,
Dom_html.inputElement'sfilesfield is typedFile.fileList Js.t Js.opt(nullable) instead of a plainFile.fileList Js.t.Ot_picture_uploader.process_fileandbind_inputcall##itemdirectly oninput##.fileswithout unwrapping theJs.opt, so the module no longer compiles against js_of_ocaml ≥ 6.4.0:This fixes both call sites by unwrapping the nullable
fileswith an extraJs.Opt.casebefore callingitem. Behaviour is unchanged for the non-null case; a nullfilesnow takes the same empty/onerrorbranch as an empty file list.Verified the exact expression type-checks against js_of_ocaml 6.x (
inputElement.files : File.fileList t opt readonly_prop).🤖 Generated with Claude Code