fix: Build-Speicher auf dem Container -- NODE_OPTIONS statt Rateschluss

Der Deploy starb mit "Ineffective mark-compacts near heap limit". Nodes
Standard-Heap richtet sich nach dem Arbeitsspeicher und liegt auf dem
Container bei rund 1,5 GB -- zu wenig fuer next build. update-app.sh setzt
jetzt --max-old-space-size=2048.

Ich hatte zuerst ESLint im Build verdaechtigt (mein ignoreDuringBuilds:
false aus v1.117.4) und die Aenderung zurueckgenommen. Eine Messung
widerlegte das: Spitzenspeicher mit ESLint 2.590 MB, ohne 2.595 MB -- kein
Unterschied. Die Ruecknahme ist damit hinfaellig, ESLint bleibt im Build.

Der Build braucht rund 2,6 GB. Bei 3 GB Container-RAM bleibt das knapp;
NODE_OPTIONS ist die Sofortmassnahme, mehr RAM fuer LXC 202 die eigentliche
Loesung. Steht als Block J in TODO.md, zusammen mit der Alternative, den
Build auf den Spark zu verlagern.

v1.119.3

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -2,6 +2,21 @@
 
 All notable changes to this project are documented in this file.
 
+## [1.119.3] - 2026-09-07
+
+### Fixed
+- `scripts/update-app.sh` setzt beim Build `NODE_OPTIONS="--max-old-space-size=2048"`.
+  Nodes Standard-Heap richtet sich nach dem Arbeitsspeicher und landet auf dem
+  Produktionscontainer bei rund 1,5 GB — zu wenig für `next build`, der Deploy starb mit
+  `FATAL ERROR: Ineffective mark-compacts near heap limit`.
+
+### Notes
+- **Gemessen, nicht vermutet:** ESLint im Build ist *nicht* die Ursache. Spitzenspeicher
+  mit ESLint 2.590 MB, ohne 2.595 MB. `eslint.ignoreDuringBuilds` bleibt daher auf `false`
+  — eine zwischenzeitliche Rücknahme beruhte auf einer falschen Annahme.
+- Der Build braucht rund **2,6 GB**. Bei 3 GB Container-RAM bleibt das knapp; mehr Speicher
+  für LXC 202 steht als Block J in `TODO.md`.
+
 ## [1.119.2] - 2026-09-07
 
 ### Changed

TODO.md

@@ -286,6 +286,34 @@ Umgestellt auf `dataSources.query()`; die Suche filtert jetzt auf `data_source`
 
 ---
 
+## Block J — Build-Speicher auf dem Container
+
+### J1. Container-RAM erhöhen *(empfohlen)*
+- [ ] LXC 202 von 3 GB auf 6 GB anheben (Proxmox → Container → Resources → Memory)
+
+**Warum:** `next build` braucht **rund 2,6 GB Spitzenspeicher** (gemessen). Bei 3 GB
+Container-RAM bleibt fast nichts übrig — der laufende PM2-Prozess und das System teilen
+sich den Rest. Der Deploy vom 07.09. starb deshalb mit
+`FATAL ERROR: Ineffective mark-compacts near heap limit`.
+
+`scripts/update-app.sh` setzt jetzt `NODE_OPTIONS="--max-old-space-size=2048"`, weil Nodes
+Standard-Heap auf diesem Container bei nur rund 1,5 GB liegt. Das ist die Sofortmaßnahme,
+aber bei 2,6 GB Bedarf bleibt es knapp. **Mehr RAM ist die eigentliche Lösung** und in
+Proxmox ein Klick.
+
+**Nicht die Ursache — geprüft:** ESLint im Build. Gemessener Spitzenspeicher mit ESLint
+2.590 MB, ohne 2.595 MB. Kein Unterschied.
+
+### J2. Alternative: woanders bauen
+- [ ] Erwägen, den Build auf dem Spark laufen zu lassen und nur `.next/standalone` zu
+      übertragen
+
+**Warum:** Dann braucht der Produktionscontainer überhaupt keinen Build-Speicher mehr —
+er würde nur noch fertige Dateien erhalten und PM2 neu starten. Grösserer Umbau des
+Deploy-Wegs, aber die sauberste Trennung.
+
+---
+
 ## Block I — UI-Wünsche
 
 ### I1. Aktuellen Tag auch im Spaltenkopf hervorheben *(erledigt, bitte ansehen)*

next.config.js

@@ -4,8 +4,13 @@ const { version } = require('./package.json');
 const nextConfig = {
   output: 'standalone',
   eslint: {
-    // Aus: Der Build soll ESLint-Fehler melden. Warnungen (aktuell ~695, überwiegend
+    // Aus: Der Build meldet ESLint-Fehler. Warnungen blockieren ihn nicht, nur Errors.
-    // no-explicit-any) blockieren den Build nicht — nur Errors tun das.
+    //
+    // Kurzzeitig stand hier wieder true, weil ich ESLint fuer den OOM-Absturz des Builds
+    // auf dem Produktionscontainer verantwortlich hielt. Eine Messung widerlegte das:
+    // Spitzenspeicher mit ESLint 2.590 MB, ohne 2.595 MB -- kein Unterschied. Die Ursache
+    // war Nodes Standard-Heap-Limit von rund 1,5 GB; dafuer setzt scripts/update-app.sh
+    // jetzt NODE_OPTIONS.
     ignoreDuringBuilds: false,
   },
   typescript: {

package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "my-weekly-todo-list",
-  "version": "1.119.2",
+  "version": "1.119.3",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "my-weekly-todo-list",
-      "version": "1.119.2",
+      "version": "1.119.3",
       "license": "MIT",
       "dependencies": {
         "@auth/prisma-adapter": "^2.11.1",

package.json

@@ -1,6 +1,6 @@
 {
   "name": "my-weekly-todo-list",
-  "version": "1.119.2",
+  "version": "1.119.3",
   "description": "A web-based weekly task management application that organizes to-dos and calendar events in a single, intuitive weekly view",
   "main": "index.js",
   "scripts": {

scripts/update-app.sh

@@ -95,8 +95,11 @@ main() {
     log "--- Regenerating Prisma client ---"
     npx prisma generate
 
+    # Der Standard-Heap von Node richtet sich nach dem Arbeitsspeicher und landet auf
+    # diesem Container bei rund 1,5 GB. Das reichte fuer `next build` nicht mehr, der Build
+    # starb mit "JavaScript heap out of memory". 2 GB lassen genug Luft fuer den Rest.
     log "--- Building application ---"
-    npm run build
+    NODE_OPTIONS="--max-old-space-size=2048" npm run build
 
     # next.config.js sets output: 'standalone', and Next.js does NOT copy public/ or
     # .next/static/ into .next/standalone — that is a documented manual step. Skipping it