メニュー
仅用于诊断 uni-app 小程序分包场景下，分包引用的 node_modules 依赖为什么仍被打进主包 common/vendor.js，而没有进入分包 vendor.js。适用于检查 uni-app 或 HBuilderX 版本、manifest.json 的分包优化开关、pages.json 的 subPackages 配置、分包根目录 package.json、以及主包与分包对 npm 依赖的规划是否符合 uni-app 内置分包依赖能力的要求。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | uniapp-subpackage-node-modules |
| description | 仅用于诊断 uni-app 小程序分包场景下，分包引用的 node_modules 依赖为什么仍被打进主包 common/vendor.js，而没有进入分包 vendor.js。适用于检查 uni-app 或 HBuilderX 版本、manifest.json 的分包优化开关、pages.json 的 subPackages 配置、分包根目录 package.json、以及主包与分包对 npm 依赖的规划是否符合 uni-app 内置分包依赖能力的要求。 |
当用户怀疑“分包使用的 npm 依赖没有进入分包 vendor.js，而是仍在主包 common/vendor.js”时，使用这个 skill。
这个 skill 只分析 uni-app 内置的分包依赖能力 是否被正确使用，不引导外部构建后脚本，也不默认修改项目。
如果问题本质是 uni_modules、easycom 或组件目录归属，改用 uniapp-subpackage-uni-modules。
只在以下条件满足时使用：
vue3node_modules 中的 js 相关文件common/vendor.js 与分包 vendor.js 的归属以下情况不适用：
vue2uni_modulesvendor.jsmanifest.json 的目标小程序平台节点开启 optimization.subPackagesvendor.jsvue3 生效node_modules 中的 js 相关文件详细规则放在 references/node-modules-subpackage-rules.md。
先确认：
manifest.jsonpages.jsonsubPackagescommon/vendor.js、分包 vendor.js 或 node_modules如果用户在问 uni_modules、easycom、分包组件归属，不要继续用这个 skill。
优先看版本，再看其他配置。
5.04 或更高版本@dcloudio/* 构建链路依赖是否已升级到具备同等能力的版本版本过旧时，应优先标记为高风险。
重点检查两处：
manifest.json 是否开启 optimization.subPackagespages.json 的 subPackages 是否有效，root 和 pages 是否正确如果分包本身没建立成功，就不要继续讨论为什么依赖没进分包 vendor.js。
必须先把依赖分成三类：
输出时要明确提醒开发者：
package.jsonpackage.json如果某个依赖本应只属于单个分包，应检查对应分包根目录下是否维护了自己的 package.json。
例如：
pages/sub/package.json
如果这类依赖只声明在项目根 package.json，要列为高风险信号。
重点确认目标依赖是否被以下位置拉回主包：
App.vueutils/、api/、store/、hooks/只要出现这些情况，依赖继续留在主包通常是符合规则的。
如果已有小程序构建产物，继续检查：
common/vendor.jsvendor.jsvendor.js如果分包根目录没有自己的 vendor.js，回头检查版本、配置、依赖划分和引用链。
如果开发者不确定“某个分包文件到底有没有用到某个依赖”，可以先征得同意，再继续扫描代码。
扫描目标：
如果开发者没有同意继续扫描，就停在规则说明、人工检查口径和操作步骤，不要默认深入分析整个项目。
出现以下条件时，可判定为“已基本满足 uni-app 内置能力前提”：
vue3manifest.json 已开启分包优化pages.json 分包有效package.json出现以下任一情况时，应直接说明为什么它不会进入分包 vendor.js：
vue3optimization.subPackagesvendor.jspackage.json拿到项目后，按下面顺序输出：
manifest.json 的分包优化配置pages.json 的 subPackagespackage.json逐条列出，并说明依据来自哪个文件或哪个现象。
manifest.json 配置package.jsonvendor.jscommon/vendor.js 和分包 vendor.js 搜索目标依赖如果用户问“接下来怎么做”，按 dd.md 的顺序给步骤，只给步骤，不直接修改：
manifest.json 的目标小程序平台节点开启 optimization.subPackagespackage.jsonpackage.jsonvendor.jscommon/vendor.js 转移到分包 vendor.js如果证据不足，就明确说“目前只能做源码层判断”。
我先按 uni-app 内置的分包依赖规则帮你判断这个问题是否成立。
我会先检查：
1. uni-app / HBuilderX / CLI 版本
2. manifest.json 是否开启 optimization.subPackages
3. pages.json 是否配置了有效分包
4. 你是否已经先做了主包依赖、单分包依赖、共享依赖的划分
5. 分包根目录下是否已经有自己的 package.json
先说明一个关键前提：只有只被单个分包使用的 node_modules js 依赖，才适合进入该分包的 vendor.js。被主包或多个分包共用的依赖，继续留在 common/vendor.js 往往是正常结果。
这个能力不能脱离“依赖划分”单独看。
你需要先把依赖分成三类：
- 主包专用依赖
- 单个分包专用依赖
- 主包和多个分包共享的依赖
如果这一步还没做，建议先不要急着判断为什么 vendor.js 没拆开。
如果你愿意，我可以继续帮你检测“某个分包下面的哪些文件实际引用了哪些依赖”，再据此判断哪些依赖符合这个优化规则。
这一步我会重点识别：
- 哪些依赖只被单个分包使用
- 哪些依赖被主包引用了
- 哪些依赖被多个分包共用了
如果你同意，我再继续做这一步扫描；如果不同意，我就只给你人工检查口径和操作步骤。
基于当前扫描结果，可以先这样分：
- 适合尝试进入分包 vendor.js 的依赖：
- 建议继续留在主包 common/vendor.js 的依赖：
判断依据：
- 是否只在单个分包目录出现
- 是否被 App.vue、主包页面或根目录共享模块引用
- 是否被多个分包同时引用
如果你要按 dd.md 这套方式落地，建议按这个顺序操作：
1. 先在 manifest.json 的目标小程序平台节点开启 optimization.subPackages
2. 先完成依赖划分，确认哪些依赖只属于某一个分包
3. 在对应分包根目录新增 package.json
4. 把该分包专用依赖写入这个分包自己的 package.json
5. 安装该分包需要的依赖
6. 重新执行小程序打包
7. 检查产物，确认分包根目录是否生成自己的 vendor.js
8. 再核对目标依赖是否已经从 common/vendor.js 转移到分包 vendor.js
这一步只建议给操作步骤，不要默认直接改项目。
rg --files <项目目录> | rg 'manifest\.json$|pages\.json$|package\.json$|unpackage|dist'
rg -n '"subPackages"|optimization|mp-weixin' <项目目录>/manifest.json <项目目录>/pages.json
rg --files <项目目录> | rg '/package\.json$'
rg -n 'from .*(lodash-es|axios|dayjs)|require\\(' <项目目录>
rg --files <产物目录> | rg 'vendor\.js$'
rg -n 'lodash-es|axios|dayjs' <产物目录> -g 'vendor.js'
如果用户已经给出具体依赖名，把示例包名替换成真实依赖名。
如果用户同意继续做依赖划分扫描，可以补充：
rg -n "from '依赖名'|from \"依赖名\"|require\\('依赖名'\\)|require\\(\"依赖名\"\\)" <项目目录>
rg -n "from '依赖名/|from \"依赖名/|require\\('依赖名/|require\\(\"依赖名/" <项目目录>