如何通过GitLab CI/CD发布包含打包资源的Composer包

完全可以实现，全程不需要把JS、CSS构建产物提交到代码仓库，核心是调整GitLab CI流水线的产物传递逻辑和Composer打包规则，具体步骤如下：

• 调整流水线阶段顺序与产物传递配置
  将静态资源构建任务放在Composer打包任务之前，在静态资源构建任务中配置artifacts规则，把构建输出目录（常见如public/build/、dist/）设为跨阶段传递的产物，保证后续打包任务可以直接拿到已经构建完成的静态文件，不需要重复构建，也不需要把这类文件纳入Git版本控制。仓库根目录的.gitignore里正常保留构建产物目录的忽略规则即可。
• 配置Composer打包的文件过滤规则
  编辑项目根目录的composer.json，添加archive配置项，明确指定打包时的包含/排除路径：排除未编译的前端源码目录、node_modules这类开发依赖目录，同时显式声明包含CI构建生成的静态资源目录，避免打包时默认过滤掉未纳入Git版本跟踪的文件。参考配置：

  {
    "name": "your-vendor/your-package",
    "archive": {
      "exclude": [
        "/node_modules",
        "/resources/js/**",
        "/resources/css/**",
        "!/public/build/**"
      ]
    }
  }
  

• 在CI工作区直接完成Composer包打包
  打包时不要直接基于Git标签、Git仓库快照生成归档包，要在已经拉取到前端构建产物的CI工作目录下执行打包命令，比如直接运行composer archive --format=zip生成归档包，此时工作区内已经存在构建好的静态资源，生成的包自然会包含这些文件。
• 正确配置Composer包的分发源
  不要使用Git仓库自动生成的源码归档作为Composer包的分发源，要把CI流程中生成的、带静态资源的归档包上传到私有Composer仓库（比如自建Satis、GitLab Package Registry）。同时在包配置中优先使用dist类型作为分发源，避免用户安装时拉取不带构建产物的Git源码。

常见踩坑排查：如果打包后静态资源仍然缺失，优先检查两个点：一是打包任务的工作区里确实存在构建完成的静态文件，可以在打包脚本前加一行ls public/build做前置校验；二是composer.json的archive规则顺序正确，排除规则没有覆盖后面的静态资源包含规则。

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