sharp is a declared dependency, and setup checks both it and ffmpeg

sharp does the images now; ffmpeg keeps the video. each does the job it is for —
sharp is libvips in-process, no process to spawn and no pipe, which is an order of
magnitude less work for the common case of a folder of photographs. a video has no
frame until something decodes one, and that is ffmpeg's and nobody else's.

added through the procedure bunfig.toml describes, since there is no
--no-frozen-lockfile flag in bun 1.3.14: package.json edited, frozenLockfile
commented out for ONE command, lockfile diff read, setting put back, and a frozen
install confirmed clean afterwards.

WHAT THE LOCKFILE DIFF ACTUALLY SAID, because the friction is only worth anything
if somebody reads it. everything is inside sharp's tree: sharp 0.33.5 -> 0.35.4 at
top level, @img/colour added, and the per-platform libvips binaries moved 1.2.4 ->
1.3.3. two SHARED packages moved with it — semver 7.7.4 -> 7.8.5 and
@emnapi/runtime 1.8.1 -> 1.11.3 — both forced by sharp's own ranges, and both
previous consumers (next, editorconfig) kept pinned copies of what they had. next
keeps its own sharp at 0.33.5 entirely. nothing outside that moved.

^0.35.3 to match what av-club declares. 0.x caret pins the minor, so ^0.33 and
^0.35 do not overlap — the plugin intersection would have resolved two native
libvips trees onto one machine for no reason.

THE IMAGE LIST GREW: libvips reads HEIC and SVG and ffmpeg does not, and neither is
exotic — HEIC is what every recent iPhone writes, and a folder of them drawing
generic file icons was the most visible gap this had.

`failOn: 'none'` and `limitInputPixels: false` are both deliberate. libvips rejects
a file with any warning in it, and a truncated JPEG — an interrupted copy, a phone
that died mid-write — is exactly that; refusing it would make this browser stricter
than the viewer somebody opens the file with. the pixel ceiling is a DoS guard for
an upload endpoint, and these are the owner's own files already on the owner's own
disk: a panorama is not an attack.

SETUP, both halves:

ffmpeg was never in the package list at all, on any of the four package managers,
despite this router shelling out to it for subtitles, audio extraction and audio
tracks long before thumbnails existed. it worked because every machine set up by
hand already had it. now declared.

sharp gets a LOAD CHECK beside node-pty's build check, and reported separately from
it. same failure shape — an install that succeeds while the native module does not
— but the opposite cause: node-pty compiles and can fail to, sharp downloads a
libvips binary for this exact platform and arch and can fail to resolve one. a
combined "native modules" verdict would send somebody to rebuild the wrong thing.
loading it is the only test worth running; a directory proves nothing, and
`versions.vips` proves libvips is bound.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

scripts/setup/machine-setup/lib/packages.sh

@@ -82,6 +82,13 @@ LAST_SKIPPED=()
 # compiles a native module needs it, but it is the one to move out first if that
 # ever bites.
 #
+# ffmpeg is not a convenience here, it is a hard dependency of the file browser.
+# Subtitles, audio extraction, audio track listing and video thumbnails all shell
+# out to it, so on a machine without it those features fail at the moment somebody
+# opens a folder — which reads as Officer being broken rather than as a package
+# being absent. It was missing from this list until 2026-08-29 and the features
+# worked anyway, because every machine that had been set up by hand already had it.
+#
 # inotify-tools is `inotifywait`, and it is what lets a COMMANDER react the
 # moment a file lands instead of polling for it. Without it a watcher can only
 # ask "is there anything new?" on a timer, which is both slower and more work —
@@ -109,24 +116,24 @@ pkgs_core() {
       echo curl ca-certificates gnupg git jq unzip \
         apt-transport-https lsb-release software-properties-common \
         wget zip brotli build-essential python3 btop tree tmux ripgrep fd-find net-tools eza \
-        inotify-tools poppler-utils fail2ban unattended-upgrades
+        inotify-tools poppler-utils ffmpeg fail2ban unattended-upgrades
       ;;
     pacman)
       echo curl ca-certificates gnupg git jq unzip \
         wget zip brotli base-devel python btop tree tmux ripgrep fd net-tools eza \
-        inotify-tools poppler fail2ban
+        inotify-tools poppler ffmpeg fail2ban
       ;;
     dnf)
       echo curl ca-certificates gnupg2 git jq unzip \
         wget zip brotli python3 btop tree tmux ripgrep fd-find net-tools eza \
-        inotify-tools poppler-utils fail2ban
+        inotify-tools poppler-utils ffmpeg fail2ban
       ;;
     brew)
       # curl, unzip and the TLS roots ship with macOS; the compilers come from
       # the Xcode command line tools, which is not a formula — see xcode_clt_*.
       # brotli is here because macOS ships the library but not the CLI.
       #
-      echo gnupg git jq wget brotli btop tree ripgrep fd eza poppler
+      echo gnupg git jq wget brotli btop tree ripgrep fd eza poppler ffmpeg
       ;;
   esac
 }

scripts/setup/officer-setup.sh

@@ -405,6 +405,7 @@ if ! skip; then
   info "Dependencies — bun install, as ${USERNAME}"
   echo "     node_modules: $(deps_installed && echo present || echo 'not there')"
   echo "     node-pty:     $(node_pty_built && echo built || echo 'not built')"
+  echo "     sharp:        $(sharp_loads && echo "loads (libvips $(sharp_version))" || echo 'does not load')"
   echo ""
   echo "     The lockfile is frozen: bun resolves from bun.lock and nothing else,"
   echo "     so a package.json that disagrees with it fails rather than quietly"
@@ -412,12 +413,29 @@ if ! skip; then
   echo ""
   echo "     node-pty has no Linux prebuild, so this compiles it from source"
   echo "     every time — which is what build-essential and python3 are for."
+  echo ""
+  echo "     sharp is the opposite problem: it does not compile, it downloads a"
+  echo "     libvips binary for this exact platform and architecture. So the"
+  echo "     install can succeed and the module still not load, and the way that"
+  echo "     shows up is a file browser drawing generic icons over a folder of"
+  echo "     photographs. Loading it is the only check worth running."
 
-  if deps_installed && node_pty_built; then
-    ok "already installed, and node-pty is built"
+  if deps_installed && node_pty_built && sharp_loads; then
+    ok "already installed; node-pty built and sharp loads"
     SUMMARY+=("Dependencies: already installed")
   elif confirm "Install them?"; then
     if install_deps; then
+      # Reported separately from node-pty rather than as one "native modules"
+      # verdict: they fail for different reasons and want different fixes, and a
+      # combined line sends somebody to rebuild the wrong one.
+      if ! sharp_loads; then
+        warn "installed, but sharp does not load"
+        echo "     Image thumbnails in the file browser will silently fall back to"
+        echo "     file icons. Usually the platform-specific binary did not resolve:"
+        echo "       cd $(platform_dir) && bun install --force"
+        ERRORS+=("Dependencies: sharp does not load")
+      fi
+
       if node_pty_built; then
         ok "installed, node-pty built"
         SUMMARY+=("Dependencies: installed")

scripts/setup/officer-setup/lib/repo.sh

@@ -95,4 +95,27 @@ deps_installed() { [[ -d "$(platform_dir)/node_modules" ]]; }
 # would not start.
 node_pty_built() { compgen -G "$(platform_dir)/node_modules/node-pty/build/Release/*.node" >/dev/null 2>&1; }
 
+# sharp is libvips, and it arrives as a PREBUILT BINARY chosen by platform and
+# architecture — @img/sharp-linux-x64 and its libvips, or the arm64 pair, or the
+# musl ones. bun picks them from the lockfile's optional dependencies.
+#
+# Which means the install can succeed and the module can still be unusable: a
+# lockfile written on x64 carries the x64 binaries, and on a machine where the
+# right optional package did not resolve, `import('sharp')` throws at the first
+# call rather than at install time. Same failure shape as node-pty above, and the
+# same reason to check it here — the symptom otherwise is a file browser drawing
+# generic icons over a folder of photographs, which nobody reads as "a native
+# module is missing".
+#
+# Loading it is the only test worth running. A directory being present proves
+# nothing; sharp's own `versions.vips` proves libvips is there and bound.
+sharp_loads() {
+  as_owner "cd '$(platform_dir)' && bun -e \"import('sharp').then(m => { if (!m.default.versions.vips) process.exit(1) }).catch(() => process.exit(1))\"" >/dev/null 2>&1
+}
+
+# What libvips sharp found, for the report. Empty when it does not load at all.
+sharp_version() {
+  as_owner "cd '$(platform_dir)' && bun -e \"import('sharp').then(m => console.log(m.default.versions.vips)).catch(() => {})\"" 2>/dev/null | tr -d '\r'
+}
+
 install_deps() { as_owner "cd '$(platform_dir)' && bun install 2>&1"; }