next build id
1.0.0
Utilisez un ID de construction cohérent et basé sur Git pour votre application Next.js
Petit package pour générer un ID de construction cohérent basé sur GIT pour votre application Next.js lors de l'exécution next build sur chaque serveur dans un déploiement multi-serveur.
Ce module exporte une fonction que vous pouvez utiliser comme votre option de configuration généréeBuildid dans next.config.js.
Par défaut, il utilisera le dernier hachage GIT Commit du référentiel GIT local (équivalent de git rev-parse HEAD ):
// next.config.js
const nextBuildId = require ( 'next-build-id' )
module . exports = {
generateBuildId : ( ) => nextBuildId ( { dir : __dirname } )
}
// => 'f9fc968afa249d162c924a8d5b4ce6562c164c2e' Si vous préférez utiliser un ID de construction par rapport à la balise la plus récente de votre référentiel Git, passez describe: true comme une option et la sortie de git describe --tags seront utilisés à la place:
// 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) Ce module expose également une version synchrone pour les besoins personnalisés, par exemple, transmettant l'ID de construction directement à une configuration de sentinelle. Appelez simplement nextBuildId.sync({ dir: __dirname }) à la place.
Si vous exécutez plusieurs instances de votre application assis derrière un équilibreur de charge sans affinité de session (et que vous construisez votre application directement sur chaque serveur de production au lieu de le préemballer), un outil comme celui-ci est nécessaire pour éviter les erreurs Suivant.js comme "Hash de fichier de construction non valide", qui se produit lorsque le même client (code du navigateur) parle à plusieurs arrière-serveurs de serveurs (serveur nœud) qui ont différents ID de construction.
L'ID de construction utilisé par votre application est stocké sur le système de fichiers dans un fichier texte BUILD_ID dans votre répertoire de build, qui est .next par défaut.
$ npm i next-build-id Ce module exporte deux fonctions, une qui est asynchrone ( nextBuildId() Exportation primaire) et une qui est synchrone ( nextBuildId.sync() ). Les deux fonctions acceptent un objet d'options unique, prenant en charge les mêmes options répertoriées ci-dessous. Les deux fonctions retournent (ou résolvent à) une chaîne, représentant l'ID de construction basé sur GIT.
Les options prises en charge sont:
dir (String, par défaut process.cwd() ): un répertoire dans le référentiel GIT local
L'utilisation __dirname à partir de votre module Next.config.js est généralement sûr. La valeur par défaut est supposée être le répertoire à partir duquel vous exécutez la next build , mais cela peut ne pas être correct en fonction de la façon dont vous créez votre application Next.js.
describe (booléen, par défaut false ): utilisez la description de la balise git au lieu du dernier engagement sha
Spécifiez cela comme true à utiliser git describe --tags au lieu de git rev-parse HEAD pour générer l'ID de construction. S'il n'y a pas de balises dans votre référentiel GIT local, le dernier engagement SHA sera utilisé à la place, sauf si vous spécifiez également fallbackToSha: false .
fallbackToSha (booléen, par défaut true ): Fallback au dernier engagement sha Quand describe: true et aucune étiquette n'existe
Ne s'applique que lorsque vous utilisez describe: true . Si vous voulez être strict d'exiger l'utilisation (et la présence) des balises, alors désactivez cela avec fallbackToSha: false , auquel cas une erreur sera lancée si aucune étiquette n'existe.
Notez que ce module fournit vraiment un moyen générique d'obtenir une chaîne d'ID ou d'état pour tout référentiel GIT local, ce qui signifie qu'il n'est pas directement lié à Next.js de quelque manière que ce soit - cela dépend simplement de la façon dont vous l'utilisez.
ISC © Andrew Goode
