@types/express-serve-static-core/index.d.ts 引发构建错误求助

• 锁定依赖版本一致性
  本地和Bitbucket流水线的依赖版本可能存在差异：本地依赖由package-lock.json锁定，而流水线如果未使用该文件，会拉取最新兼容版本，导致编译环境不一致。
  解决：确保package-lock.json已提交到仓库，流水线执行npm install时默认会读取该文件安装和本地完全一致的依赖；如果流水线配置中使用了npm install --no-package-lock，需移除该参数。

• 对齐Node.js/npm版本
  本地与流水线使用的Node.js、npm版本不匹配是常见诱因，部分包对Node版本有严格要求，版本差异会触发编译错误。
  解决：在项目根目录添加.nvmrc文件指定Node版本（比如18.17.0），流水线中先安装对应版本；或在bitbucket-pipelines.yml里指定与本地一致的Node镜像（例如image: node:18.17.0-alpine）。

• 补充流水线缺失的系统依赖
  本地环境可能存在全局工具、系统库（如Python、编译工具链），而流水线的Docker镜像默认未包含这些依赖，导致编译失败。
  解决：在流水线的script步骤中添加系统依赖安装命令，例如基于Alpine镜像可执行apk add --no-cache python3 make g++；检查项目编译是否依赖特定环境变量，在流水线配置中添加对应变量。

• 清理流水线缓存
  Bitbucket流水线的node_modules缓存可能已损坏或与新依赖冲突，导致安装的依赖不完整。
  解决：在流水线执行npm install前，添加清理命令：rm -rf node_modules package-lock.json，确保每次安装干净的依赖；也可在Bitbucket后台手动清除流水线缓存。

• 排查代码变更的隐性影响
  即使你认为代码变更与依赖、流水线无关，部分代码修改可能触发了依赖包的隐藏兼容性问题（例如组件写法与新版本依赖的特性冲突，而本地旧依赖可兼容）。
  解决：回滚最近的代码变更，验证流水线是否恢复正常；若恢复，逐步排查具体代码行的冲突点。

内容的提问来源于stack exchange，提问作者LST