从GitHub仓库安装npm包缺失dist文件夹的最佳实践咨询

核心结论 #

不推荐将dist构建产物提交到Git仓库，这不是前端社区的通用最佳实践。提交dist目录确实会引发合并冲突、仓库体积冗余、源码与构建产物版本不一致等问题，你的顾虑是完全合理的。

可行解决方案 #

方案1：使用prepare脚本（最适配当前场景） #

npm 6及以上版本、pnpm、yarn均原生支持prepare脚本的特殊逻辑，完美解决你提到的postinstall的缺陷：

• 从Git源安装包时，npm会自动为该包安装其devDependencies
• 自动执行prepare脚本，执行完成后自动清理多余的dev依赖，不会占用额外空间
• 本地开发执行npm link时也会自动触发，不影响本地调试流程

配置方式如下，在你的npm包的package.json中添加对应脚本即可：

{
  "scripts": {
    "build": "你的构建命令，比如tsc && vite build",
    "prepare": "npm run build"
  }
}

配置完成后直接用原有Git分支地址安装即可，无需修改安装命令。

方案2：发布预发布版本到npm registry #

如果你的包有CI/CD流程，可以给开发分支配置自动发布预发布版本的逻辑，每次分支代码更新时，自动发布带版本后缀的版本，比如1.0.0-beta.xxxx（后缀可以用commit hash或者构建序号），安装时直接指定对应预发布版本号即可。
这个方案的优势是不需要每次安装都重新执行构建，安装速度更快，稳定性更高，适合团队内部协作场景。

方案3：CI自动推送构建产物到专属分支 #

如果不想发布到npm registry，可以配置CI流程：开发分支代码更新时，自动执行构建，将dist目录推送到和开发分支绑定的专属构建分支（比如build/[开发分支名]），安装时指定对应的构建分支地址即可。
这个方案既可以避免开发分支提交dist带来的冲突问题，也不需要用户安装时本地执行构建，适合有CI能力但不方便发布到npm registry的场景。

不推荐的方案 #

• 不要使用postinstall脚本实现构建逻辑：postinstall执行时不会自动安装依赖的devDependencies，而且会在已发布的npm包安装时也触发，既会拖慢安装速度，也存在安全风险。

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