Composer如何管理自定义的模板文件_利用脚手架插件功能【效率利器】-composer-PHP中文网

composer create-project 仅识别 type: "project" 的包作为模板，否则会误装入 vendor/；必须在模板包的 composer.json 中正确定义 type 和 post-create-project-cmd 脚本，且通过合法 vcs 仓库发布。

composer如何管理自定义的模板文件_利用脚手架插件功能【效率利器】

composer create-project 本身不支持“模板文件”概念，它只认包（package）——你得把模板做成一个可安装的 type: "project" 包，否则所有所谓“自定义模板”的操作都会失败或误入 vendor。

根本原因是包的 "type" 字段没设对。Composer 只有在识别到 "type": "project" 时，才触发 create-project 的骨架复制逻辑；否则一律按普通库处理，直接 require 进 vendor/。

"type": "library"（默认值）或未声明 type → 模板包被当成依赖装进 vendor/your-vendor/template，毫无意义
"type": "project" → Composer 克隆整个仓库到目标目录，清空 .git，执行脚本，这才是你要的效果
别信“只要带 composer.json 就能当模板”——没 type，就等于没身份证

这个钩子只在新项目（即目标目录）的 composer.json 里定义才生效，不是在模板源码的 composer.json 里写。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

脚本必须写在**模板包自己的 composer.json** 中，且字段名是 "post-create-project-cmd"（注意拼写和大小写）
执行时工作目录是新建项目的根目录，原始模板仓库已不存在——不能用 ../template/src 这类相对路径读文件
命令中若调用 CLI 工具（如 php artisan key:generate），需确保该工具已在新项目中可用（即已通过 require 声明或自带）

用 --repository 手动指定 URL 容易出错，尤其当模板未发布到 Packagist 时，更推荐显式声明 VCS 类型 + 使用完整包名。

正确姿势：composer create-project your-vendor/my-template my-app --repository='{"type":"vcs","url":"https://gitlab.internal/my-template"}'
错误姿势：composer create-project --repository=https://gitlab.internal/my-template.git ...（URL 不是合法 repository 配置）
如果模板在 GitHub 私有库，确保当前机器已配置 SSH key 或 token 认证，否则 clone 会失败并静默退出

模板里写 "App\": "src/" 没问题，但像 APP_NAME=MyProject 这种变量，不能指望开发者去改 .env。

用 post-create-project-cmd 自动 copy + 替换：@php -r "file_put_contents('.env', str_replace('MY_APP', 'my-app', file_get_contents('.env.example')));"
避免在模板中写 "require": { "your-vendor/my-template": "*" } —— 这会造成循环依赖，create-project 直接报错
打 tag 要明确：v1.0.0 比 dev-main 更稳定；私有库记得同步 tag 到服务器，否则 create-project your-vendor/my-template my-app v1.0.0 会找不到版本

真正卡住人的从来不是命令怎么敲，而是搞不清 create-project 实际上是在“安装一个包”，而不是“复制一堆文件”。模板仓库的 composer.json 必须能独立安装、运行、被索引——它就是一个普通包，只是用途特殊而已。