next build id
1.0.0
Verwenden Sie eine konsistente GIT-basierte Build-ID für Ihre nächste.js-App
Kleines Paket zum Generieren einer konsistenten, GIT-basierten Build-ID für Ihre nächste.js-App beim Ausführen next build auf jedem Server in einer Bereitstellung von Multi-Server.
Dieses Modul exportiert eine Funktion, die Sie als Option für generateBuildid -Konfiguration in Next.config.js verwenden können.
Standardmäßig wird es den neuesten Git Commit Hash aus dem lokalen Git-Repository (gleichwertig zu git rev-parse HEAD ) verwenden:
// next.config.js
const nextBuildId = require ( 'next-build-id' )
module . exports = {
generateBuildId : ( ) => nextBuildId ( { dir : __dirname } )
}
// => 'f9fc968afa249d162c924a8d5b4ce6562c164c2e' Wenn Sie lieber eine Build -ID in Bezug auf das neueste Tag in Ihrem Git -Repo verwenden möchten, wird bestehen describe: true als Option und die Ausgabe von git describe --tags -werden stattdessen verwendet.
// next.config.js
const nextBuildId = require ( 'next-build-id' )
module . exports = {
generateBuildId : ( ) => nextBuildId ( { dir : __dirname , describe : true } )
}
// => 'v1.0.0' (no changes since v1.0.0 tag)
// => 'v1.0.0-19-ga8f7eee' (19 changes since v1.0.0 tag) In diesem Modul wird auch eine synchrone Version für benutzerdefinierte Anforderungen enthüllt, z. B. die Build -ID direkt an eine Sentry -Konfiguration. Rufen Sie nextBuildId.sync({ dir: __dirname }) statt.
Wenn Sie mehrere Instanzen Ihrer App ausführen, die ohne Sitzungsaffinität hinter einem Load-Balancer sitzt (und Ihre App direkt auf jedem Produktionsserver anstelle des Vorverpackens erstellt), ist ein Tool wie dieses erforderlich, um Next.js-Fehler wie "Ungültiges Build-Datei-Hash" zu vermeiden, der passiert, wenn derselbe Client (Browsercode) mit mehreren Server-Backends (Node-Server) mit unterschiedlichen Build-IDs gesprochen wird.
Die von Ihrer App verwendete Build -ID wird im Dateisystem in einer Textdatei BUILD_ID in Ihrem Build -Verzeichnis gespeichert, die standardmäßig .next ist.
$ npm i next-build-id Dieses Modul exportiert zwei Funktionen, eine, die asynchron ist ( nextBuildId() Primärxport) und eine, die synchron ist ( nextBuildId.sync() ). Beide Funktionen akzeptieren ein einzelnes Optionsobjekt und unterstützen dieselben Optionen, die unten aufgeführt sind. Beide Funktionen geben eine Zeichenfolge zurück (oder beheben), die die GIT-basierte Build-ID darstellt.
Die unterstützten Optionen sind:
dir (String, Standard process.cwd() ): Ein Verzeichnis im lokalen Git -Repository
Die Verwendung von __dirname aus Ihrem nächsten.config.js -Modul ist im Allgemeinen sicher. Es wird angenommen, dass der Standardwert das Verzeichnis ist, aus dem Sie den next build -Befehl ausführen. Dies ist jedoch möglicherweise nicht korrekt, basierend darauf, wie Sie Ihre nächste.js -App erstellen.
describe (boolean, Standard false ): Verwenden Sie die Git -Tag -Beschreibung anstelle des neuesten Commit SHA
Geben Sie dies als true für die Verwendung git describe --tags anstelle von git rev-parse HEAD zum Generieren der Build-ID. Wenn Ihr lokales Git -Repository keine Tags gibt, wird das neueste Commit SHA stattdessen verwendet, es sei denn, Sie geben fallbackToSha: false .
fallbackToSha (boolean, Standard true ): Fallback, um die neuesten Verpflichtungen zu begehen, wenn describe: true und keine Tags existieren
Gilt nur bei der Verwendung describe: true . Wenn Sie streng darüber nachdenken möchten, die Verwendung (und das Vorhandensein) von Tags zu verwenden, deaktivieren Sie dies mit fallbackToSha: false . In diesem Fall wird ein Fehler geworfen, wenn keine Tags vorhanden sind.
Beachten Sie, dass dieses Modul wirklich eine generische Möglichkeit bietet, eine ID oder eine Statuszeichenfolge für ein lokales Git -Repository zu erhalten, dh es ist in keiner Weise direkt an Next.js gebunden - es hängt nur davon ab, wie Sie es verwenden.
Isc © Andrew Goode
