mARTin-B78
162c56d0d3
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>
45 lines
1.7 KiB
JavaScript
45 lines
1.7 KiB
JavaScript
/** @type {import('next').NextConfig} */
|
|
const { version } = require('./package.json');
|
|
|
|
const nextConfig = {
|
|
output: 'standalone',
|
|
// Ziel des Builds. update-app.sh baut nach .next-build, damit das laufende .next
|
|
// waehrend des Builds unberuehrt bleibt, und schaltet erst nach erfolgreichem
|
|
// Smoke-Test um. Ohne das zerstoert ein fehlgeschlagener Build die laufende App.
|
|
distDir: process.env.NEXT_DIST_DIR || '.next',
|
|
eslint: {
|
|
// Aus: Der Build meldet ESLint-Fehler. Warnungen blockieren ihn nicht, nur Errors.
|
|
//
|
|
// 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: {
|
|
// Aus: Der Build bricht bei Typfehlern ab. Bis v1.118.1 stand hier true — dadurch
|
|
// liefen mehrfach fehlende Importe durch, die zur Laufzeit ReferenceError geworfen
|
|
// haetten, waehrend der Build "erfolgreich" meldete.
|
|
ignoreBuildErrors: false,
|
|
},
|
|
optimizeFonts: false,
|
|
env: {
|
|
NEXT_PUBLIC_APP_VERSION: version,
|
|
},
|
|
experimental: {
|
|
serverComponentsExternalPackages: ['ical.js', 'tsdav'],
|
|
},
|
|
webpack: (config, { isServer }) => {
|
|
// Ignore .md files in node_modules (fixes apple-icloud README.md parse error)
|
|
config.module.rules.push({
|
|
test: /\.md$/,
|
|
include: /node_modules/,
|
|
type: 'asset/source',
|
|
});
|
|
return config;
|
|
},
|
|
};
|
|
|
|
module.exports = nextConfig;
|