next build lief direkt auf .next -- also auf dem Verzeichnis, aus dem die
laufende Instanz bedient wird. Brach der Build ab, fand PM2 server.js nicht
mehr (MODULE_NOT_FOUND) und geriet in eine Neustartschleife mit ueber 790
Versuchen. Am 07.09. war die Seite dadurch rund eine Stunde unbrauchbar.
Neuer Ablauf:
1. Build nach .next-build, .next bleibt unangetastet
2. statische Dateien und .env in den neuen Baum
3. Smoke-Test: der neue Build wird auf Port 3999 gestartet und muss auf
/auth/login antworten -- ein Build kann durchlaufen und trotzdem nicht
starten
4. erst danach umschalten, alter Stand bleibt als .next-previous liegen
5. PM2 neu starten
Scheitert etwas davon, raeumt der ERR-Trap .next-build weg und die laufende
App bleibt unveraendert. Die Meldung "die laufende App bleibt unberuehrt"
stimmt damit endlich -- vorher war sie schlicht falsch.
Geprueft wurde vorher, dass der umbenannte Build ueberhaupt startet: der
standalone-Ausgabebaum traegt den distDir-Namen intern, server.js findet
seine Dateien aber relativ zu sich selbst. Testweise gestartet, Login-Seite
und JS-Dateien lieferten 200.
Beide Faelle durchgespielt: Abbruch liess .next samt Markierung unberuehrt
und raeumte .next-build weg; Erfolg schaltete um, legte .next-previous an
und bestand den Smoke-Test.
v1.120.0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
typescript.ignoreBuildErrors steht jetzt auf false. Ein erfolgreicher Build
ist damit wieder ein Beleg dafuer, dass der Code uebersetzbar ist.
Die Ursache der 30-Minuten-Laufzeit war nicht die Groesse von WeeklyView.tsx,
wie ich vermutet hatte, sondern das include-Muster **/* in tsconfig.json. Auf
src/**/* eingegrenzt laeuft der volle Typecheck in 19 Sekunden.
Die sieben gefundenen Fehler:
- notion-calendar.ts rief notion.databases.query() auf. Die Methode gibt es
in @notionhq/client v5 nicht mehr -- die Notion-Anbindung war zur Laufzeit
schlicht kaputt und niemandem aufgefallen. Migriert auf dataSources.query(),
aber mangels Notion-Zugang ungetestet. Gespeicherte Verbindungen enthalten
alte database_ids und muessen neu eingerichtet werden.
- WeeklyView.tsx importierte isAllDayEvent noch aus format statt date-utils
-- mein eigener Fehler aus v1.118.0, der ohne scharfen Typecheck
durchgerutscht war.
- Export-Helfer lagen in einer route.ts, wo Next.js nur Route-Handler
erlaubt; SettingsSidebar importierte sie von dort und zog einen
Server-Handler in den Client-Graphen. Jetzt in src/lib/export-fields.ts.
- push-notifications.ts: BufferSource-Cast fuer applicationServerKey.
- web-push hat keine Typen; lokale Deklaration statt neuer Abhaengigkeit.
Verifiziert: npm run build Exit 0 mit scharfem Typecheck, 63 Unit-Tests gruen.
v1.118.1
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
eslint.ignoreDuringBuilds stand auf true, der Build verschluckte also jede
Lint-Meldung. Im gesamten Projekt gab es genau zwei echte Errors -- beide
"let json" statt "const json" in SettingsSidebar.tsx. Behoben, Schalter aus,
next lint endet mit Exit 0.
Die 695 Warnungen (470 no-explicit-any, 209 ungenutzte Variablen, 11
unvollstaendige Hook-Abhaengigkeiten) blockieren den Build nicht. Die
Hook-Warnungen sind davon die interessantesten, weil daraus echte Bugs
entstehen -- stehen als eigener Punkt in TODO.md.
Naechster Schritt ist typescript.ignoreBuildErrors; der volle tsc-Lauf
dauert wegen WeeklyView.tsx ueber 15 Minuten und laeuft noch.
v1.117.4
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Fix Docker build: resolve hooks-rules-of-hooks in GridTaskBlock, add Suspense
boundary for useSearchParams, fix non-root user home dir and prisma binary path
- Add comprehensive DB migrations for missing columns/tables (WeeklyGoal,
CachedCalendarEvent, User settings, SomedayList sync fields, Task subtasks)
- Fix Outlook OAuth redirect using NEXTAUTH_URL instead of request.url
- Fix CalendarEventModal preserving existing event dates (support flat format)
- Fix header z-index layering so goal text doesn't block hover controls
- Convert font size selects to free-form text inputs, add dayHeaderGap setting
- Add goal 2-line clamping with 500px max width
- Fix weekend colors not applying to date elements
v1.6.0
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add isSyncing state to fetchTasks() so spinner shows during task/list loading
- Remove !task.completed filter from getTasksForDate — completed tasks now stay
visible with strikethrough instead of vanishing
- Inject package.json version into NEXT_PUBLIC_APP_VERSION via next.config.js
so the Settings > About tab always shows the current version
v1.1.1
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add Google Tasks integration and Apple Reminders support
- Add task import/export with list management APIs
- Add goal API for weekly goals
- Add German holidays library
- Add ImportListModal component
- Enhance WeeklyView with major UI improvements
- Enhance CalendarSettings with new connection options
- Add external task fields to database schema
- Add Playwright test suites for auth and tasks
- Add iCloud reminders Python scripts
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
