为您的下一个应用程序使用一致的,基于git的构建ID
小软件包在多服务器部署中的每个服务器上运行next build时,为您的下一个应用程序生成一致的,基于git的构建ID。
该模块导出一个可以用作next.config.js中的generateBuildID配置选项的函数。
默认情况下,它将使用本地GIT存储库(相当于git rev-parse HEAD )的最新git commit Hash:
// next.config.js
const nextBuildId = require ( 'next-build-id' )
module . exports = {
generateBuildId : ( ) => nextBuildId ( { dir : __dirname } )
}
// => 'f9fc968afa249d162c924a8d5b4ce6562c164c2e'如果您宁愿使用相对于git reto中最新标签的构建ID,请describe: true作为选项,而git describe --tags将被使用:
// 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)该模块还将公开一个同步版本以满足自定义需求,例如将构建ID直接传递给哨兵配置。只需致电nextBuildId.sync({ dir: __dirname }) 。
如果您在没有会话亲和力的情况下运行了坐在负载平衡器后面的多个实例(并且您直接在每个生产服务器上构建应用程序而不是预包装),则需要这样的工具来避免Next.js错误,例如“无效的构建文件哈希”,当同一客户端(浏览器代码(浏览器代码)对多个服务器后端服务器(nondode Server)对话时,它会发生不同的构建ID构建ID。
您的应用程序使用的构建ID存储在文件系统中的BUILD_ID文本文件中的构建目录中,默认情况下为.next 。
$ npm i next-build-id 该模块导出两个函数,一个功能是异步( nextBuildId()主导出),一个是同步的( nextBuildId.sync() )。这两个功能都接受单个选项对象,支持下面列出的相同选项。两个函数都返回(或解析为)字符串,代表基于GIT的构建ID。
支持的选项是:
dir (字符串,默认process.cwd() ):本地git存储库中的目录
通常使用__dirname 。通常是安全的。假定默认值是您正在运行next build命令的目录,但是根据您构建下一个js应用程序的方式,这可能不是正确的。
describe (布尔值,默认false ):使用git标签描述代替最新提交sha
将其true为使用git describe --tags而不是用于生成构建ID的git rev-parse HEAD 。如果您本地的GIT存储库中没有标签,则将使用最新的提交SHA,除非您还指定了fallbackToSha: false 。
fallbackToSha (布尔值,默认为true ): describe: true和不存在标签
仅在使用describe: true 。如果您想严格要求使用标签的使用(和存在),则使用fallbackToSha: false禁用此标签,在这种情况下,如果不存在标签,则会丢弃错误。
请注意,该模块确实提供了一种通用方法来获取任何本地GIT存储库的ID或状态字符串,这意味着它并未直接与Next.js绑定。JS以任何方式 - 仅取决于您的使用方式。
ISC©Andrew Goode