8 Commits

Author SHA1 Message Date
hsiegeln
173d9d138d fix(ai): sharp via createRequire, nicht ES-Import
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 28s
ES-Dynamic-Import mit @vite-ignore reichte nicht -- adapter-node's
Rollup-Step extrahiert sharp trotzdem in einen shared chunk und
bundelt sharp's interne dynamic-requires kaputt.

createRequire(import.meta.url) plus require('sharp') ist pure Node-
Runtime-Logik, die Rollup komplett ignoriert. sharp wird regulaer aus
node_modules geladen -- inkl. seiner Plattform-.node-Binary aus
@img/sharp-linuxmusl-arm64.

Verifikation: Build-Output enthaelt 0 Vorkommen von "dynamicRequireTargets"
und "sharp.node" (waren vorher in einem 319KB shared chunk).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 13:08:53 +02:00
hsiegeln
5492d4dc24 fix(deploy): BODY_SIZE_LIMIT=10MB fuer Foto-Upload
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 2m17s
adapter-node limitiert Request-Bodies per Default auf 512 KB.
Unsere Rezept-Fotos sind bis 8 MB gross -- der Upload scheitert
sonst vor dem Endpoint-Check mit "Multipart body erwartet", weil
SvelteKit den Body frueher abweist.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 13:05:09 +02:00
hsiegeln
39de08abf9 fix(ai): sharp via dynamic import, nicht top-level
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 2m28s
Der vorige Versuch mit ssr.external in vite.config.ts war ein No-op:
adapter-node macht einen eigenen Rollup-Bundle-Schritt nach Vite und
ignoriert ssr.external komplett. Ergebnis: sharp's dynamic-require
fuer die native .node-Binary landet kaputt im Server-Bundle (332KB
Bundle-Chunk, 297 sharp-Referenzen).

Dynamic import mit /* @vite-ignore */ verhindert, dass Rollup sharp
aufloest — die Require geht stattdessen zur Laufzeit regulaer an
Node und findet @img/sharp-linuxmusl-arm64 in node_modules.

Ergebnis lokal: Server-Chunk von 332KB auf 14KB geschrumpft, nur noch
2 Referenzen auf den Paketnamen (der Import-String selbst).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 12:33:59 +02:00
hsiegeln
fd7884e1b2 fix(vite): sharp als ssr.external markieren
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 2m17s
Der Server-Bundle-Schritt (Rollup via adapter-node) kann sharp's
dynamic-require fuer die native Plattform-.node-Binary nicht aufloesen
und bundelt kaputten Code ins Image. ssr.external sorgt dafuer, dass
sharp zur Laufzeit regulaer aus node_modules geladen wird, wo der
Docker-Build die @img/sharp-linuxmusl-arm64-Binary korrekt abgelegt hat.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 12:27:28 +02:00
hsiegeln
13728f9252 fix(docker): expliziter Plattform-Install fuer sharp-Prebuilts
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 3m5s
Finaler Anlauf gegen den arm64-Build-Fehler. Bisher scheiterte
npm daran, @img/sharp-linuxmusl-arm64 unter Docker-Buildx-QEMU zu
installieren, trotz --include=optional. Mehrschichtiger Fix:

1. --cpu=arm64 --os=linux --libc=musl auf npm install: umgeht QEMU-
   bezogene Detection-Bugs (sharp's offiziell empfohlener Fix).
2. Expliziter Zusatz-Install von @img/sharp-linuxmusl-arm64 und
   @img/sharp-libvips-linuxmusl-arm64: zwingt die Prebuilts auf Disk,
   unabhaengig von der Lockfile-Resolution.
3. --ignore-scripts beim Install + npm rebuild danach: loest den Race,
   wo sharp's postinstall laeuft bevor der Prebuilt-Tarball fertig ist.
4. node-addon-api + node-gyp als Runtime-Deps: from-source-Build-
   Fallback falls alle Prebuilt-Pfade scheitern.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:52:55 +02:00
hsiegeln
83f5b88d94 fix(docker): node-addon-api + ignore-scripts/rebuild fuer sharp
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 51s
Drei Schichten Absicherung gegen den arm64-Build-Fehler:

- --ignore-scripts beim npm install verhindert, dass sharp's postinstall
  check.js laeuft, bevor das @img/sharp-linuxmusl-arm64-Paket entpackt
  ist (Race in parallelem Install).
- npm rebuild danach: alle Deps sind jetzt auf Disk, Postinstalls laufen
  sauber in Dependency-Reihenfolge.
- node-addon-api als Runtime-Dep: falls die Prebuilt-Binary im npm-Tree
  nicht landet, kann sharp from-source bauen (vips-dev + python3 + make
  + g++ sind im Dockerfile bereits installiert).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:49:41 +02:00
hsiegeln
cb93725139 fix(docker): npm install statt npm ci fuer sharp-Prebuilts
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 48s
Der vorige Fix (ignore-scripts + rebuild, plus Fresh-ci im Builder) hat
den sharp-Prebuilt trotzdem nicht installiert. Ursache: der Windows-
generierte Lockfile markiert @img/sharp-linuxmusl-arm64 als "dev": true,
sodass npm ci die Prebuilt-Binary konsistent auslaesst — egal ob mit
--include=optional. npm install dagegen resolvt Optional-Deps frisch fuer
die Build-Plattform (linux-arm64-musl im Docker) und findet die Prebuilts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:46:55 +02:00
hsiegeln
80c72b6e5b fix(docker): sharp-Prebuilts beim CI-Build korrekt installieren
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 51s
Zwei Fixes gegen den arm64-Build-Fehler:

1. npm ci mit --ignore-scripts + npm rebuild danach — vermeidet
   eine Race, bei der sharp's postinstall check.js laeuft bevor die
   Plattform-Prebuilt-Binary vollstaendig entpackt ist.

2. Statt npm prune --omit=dev ein Fresh-Install via npm ci
   --omit=dev. Grund: Der Lockfile wird auf Windows generiert und
   markiert die linux-musl-arm64-Prebuilts als "dev": true, obwohl
   sie fuer's Runtime gebraucht werden. Prune wuerde sie kappen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:44:05 +02:00
6 changed files with 490 additions and 394 deletions

View File

@@ -8,13 +8,39 @@ WORKDIR /app
RUN apk add --no-cache python3 make g++ libc6-compat vips-dev
COPY package*.json ./
RUN npm ci
# Sharp-Prebuilt-Install unter Docker-Buildx-QEMU war trotz aller Flag-
# Varianten unzuverlaessig. Finale Strategie:
# - --cpu/--os/--libc explizit setzen: sharp's offizielle Doc-Empfehlung
# fuer Cross-Platform-Docker-Builds (siehe sharp-Install-Doku),
# umgeht QEMU-Detection-Bugs.
# - --ignore-scripts + npm rebuild: loest das Parallel-Install-Race,
# bei dem sharp's install-Skript vor dem Entpacken der Prebuilt-Binary
# laeuft.
# - Explizites Nachinstallieren der Prebuilts als Sicherheit: falls (A)
# noch nicht reicht, zwingt (B) die Plattform-Pakete auf Disk.
# - node-addon-api + node-gyp als Runtime-Deps: falls am Ende doch alles
# nicht klappt und sharp from-source baut (mit dem oben installierten
# python3 + make + g++ + vips-dev).
RUN npm install --cpu=arm64 --os=linux --libc=musl \
--ignore-scripts --include=optional --no-audit --no-fund
RUN npm install --cpu=arm64 --os=linux --libc=musl \
--ignore-scripts --no-save --no-audit --no-fund \
@img/sharp-linuxmusl-arm64@0.34.5 \
@img/sharp-libvips-linuxmusl-arm64@1.2.4
RUN npm rebuild
COPY . .
RUN npm run build
# Remove dev dependencies for the runtime image
RUN npm prune --omit=dev
# Fresh-Install fuer den Runtime-Stage: nur Produktions-Deps, gleiche Strategie.
RUN rm -rf node_modules \
&& npm install --cpu=arm64 --os=linux --libc=musl \
--ignore-scripts --omit=dev --include=optional --no-audit --no-fund \
&& npm install --cpu=arm64 --os=linux --libc=musl \
--ignore-scripts --no-save --no-audit --no-fund \
@img/sharp-linuxmusl-arm64@0.34.5 \
@img/sharp-libvips-linuxmusl-arm64@1.2.4 \
&& npm rebuild
FROM node:22-alpine AS runner
WORKDIR /app

View File

@@ -17,6 +17,9 @@ services:
- GEMINI_API_KEY=${GEMINI_API_KEY:-}
- GEMINI_MODEL=${GEMINI_MODEL:-gemini-2.5-flash}
- GEMINI_TIMEOUT_MS=${GEMINI_TIMEOUT_MS:-20000}
# adapter-node-Default ist 512 KB; Rezept-Fotos koennen bis 8 MB sein.
# Multipart-Overhead einrechnen -> 10 MB gibt etwas Puffer.
- BODY_SIZE_LIMIT=10000000
depends_on:
- searxng
restart: unless-stopped

822
package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@@ -42,6 +42,8 @@
"better-sqlite3": "^11.5.0",
"linkedom": "^0.18.5",
"lucide-svelte": "^1.0.1",
"node-addon-api": "^8.7.0",
"node-gyp": "^12.3.0",
"yauzl": "^3.3.0",
"zod": "^3.23.8"
}

View File

@@ -1,4 +1,5 @@
import sharp from 'sharp';
import type SharpType from 'sharp';
import { createRequire } from 'node:module';
const MAX_EDGE = 1600;
const JPEG_QUALITY = 85;
@@ -8,10 +9,25 @@ export type PreprocessedImage = {
mimeType: 'image/jpeg';
};
// sharp per Node-Runtime-require laden, nicht via ES-Import: adapter-node
// bundelt ES-Imports (auch dynamische, auch mit @vite-ignore) ins Server-
// Bundle, was sharp's internes dynamic-require fuer die Plattform-.node-Binary
// zerstoert. createRequire + require() ist pure Node-Runtime-Logik, die
// Rollup nicht anfasst -- sharp wird regulaer aus node_modules geladen.
const nodeRequire = createRequire(import.meta.url);
let sharpModule: typeof SharpType | null = null;
function loadSharp(): typeof SharpType {
if (!sharpModule) {
sharpModule = nodeRequire('sharp') as typeof SharpType;
}
return sharpModule;
}
// Resize auf max 1600px lange Kante, JPEG re-encode, Metadata strippen.
// sharp liest HEIC/HEIF transparent, wenn libheif im libvips-Build enthalten ist
// (in Alpine's vips-dev + in den offiziellen sharp-Prebuilds).
export async function preprocessImage(input: Buffer): Promise<PreprocessedImage> {
const sharp = loadSharp();
const pipeline = sharp(input, { failOn: 'error' }).rotate(); // respect EXIF orientation
const meta = await pipeline.metadata();
if (!meta.width || !meta.height) {

View File

@@ -3,6 +3,13 @@ import { defineConfig } from 'vitest/config';
export default defineConfig({
plugins: [sveltekit()],
// sharp muss extern bleiben: der Server-Bundle-Schritt kann sharp's
// dynamic-require fuer die native .node-Binary nicht aufloesen. Wenn
// sharp nicht gebundelt wird, laedt Node es zur Laufzeit regulaer aus
// node_modules/@img/sharp-linuxmusl-arm64, das dann funktioniert.
ssr: {
external: ['sharp']
},
test: {
include: ['tests/**/*.test.ts'],
globals: false,