Composer 不能管理 Node.js 资源，它只处理 PHP 依赖；正确做法是 Composer 与 npm/pnpm 并行协作，各司其职：前者管后端，后者管前端构建。
Composer 不能管理 Node.js 资源 —— 它压根不处理 node_modules、package.json 或任何 JavaScript 运行时依赖。强行用 Composer 下载前端包（比如通过 fxp/composer-asset-plugin 或自定义 installer）属于历史遗留方案，现在既不安全也不可持续。
为什么 composer require npm-asset/jquery 现在基本走不通
过去有人用 fxp/composer-asset-plugin 把 Bower 包转成 Composer 包，后来 Bower 死了，npm 成为主流，但该插件从未原生支持 npm registry。社区尝试过 fork（如 composer-asset-plugin 的 npm 分支），但存在严重问题：
- 无法正确解析
peerDependencies和optionalDependencies - 不校验
integrity字段，容易引入被篡改的包 - 无法运行
postinstall脚本（比如构建 CSS/JS），导致dist/文件缺失 - PHP 8+ 下多数分支已编译失败，官方早已归档（archived）
真正可行的共存方案：Composer + npm/yarn/pnpm 并行管理
现代 PHP 项目（如 Laravel、Symfony）默认采用「分层职责」：Composer 管 PHP 依赖，Node.js 工具链管前端资源。关键不是“集成”，而是“协同”：
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- 把
package.json放在项目根目录或resources/js/下，用npm install或pnpm install独立安装 - 在
composer.json的scripts里声明钩子，例如："scripts": { "post-install-cmd": ["npm ci --no-audit"], "post-update-cmd": ["npm ci --no-audit"] } - 构建产物（如
public/build/app.js）不进 Git，由 CI 或本地npm run build生成 - PHP 代码只引用最终产出路径（如
<script src="/build/app.js"></script>），不碰node_modules
如果必须从 PHP 侧触发前端构建：用 exec() 而非假装集成
有些部署环境限制多（比如仅开放 composer install 权限），这时与其魔改 Composer，不如明确调用 Node.js 工具：
立即学习“前端免费学习笔记（深入）”；
- 确认服务器已装 Node.js（检查
node -v和npm -v） - 在
composer.json中写："scripts": { "post-install-cmd": ["cd resources/js && npm ci && npm run build"] } - 避免用
system()或shell_exec()在 PHP 里硬编码命令 —— 构建逻辑应收敛在package.json#scripts中 - 注意工作目录：Composer 默认在项目根执行脚本，
cd切换后需确保路径存在且权限正确
最常被忽略的一点：node_modules 不是资产（asset），它是构建过程的临时工。把它当 Composer 包来 require，就像试图用 apt install 管理 Python 的 __pycache__ —— 方向错了，越用力越卡死。
