Vite license 文件出现 0.0.0，检查依赖内部的 package.json 标记

启用 Vite 的 build.license 后，生成文件列出了依赖名字，却把版本写成 0.0.0，同时缺少许可标识或正文，可以先检查包内部有没有额外的 package.json。项目安装的真实版本可能完全正确，出错的是构建器给模块归属的包边界。

一种已确认的布局是双 ESM/CJS 包在子目录放置类型标记。例如 engine.io-client 的真实包根记录 6.6.3、MIT 与许可文件，build/esm/package.json 却只有 name、type、browser 等字段。受影响查找遇到这个带 name 的内部标记便停止，license 生成器拿到缺少版本和许可信息的对象，默认版本就成了 0.0.0。

具体报告涉及 Vite 7.3.1 及 Vite 8 的对应构建路径，使用 socket.io-client 与其传递依赖作为例子。Vite 8 的确切小版本没有在该处完整列出，不能补成某一个版本，更不能认定所有缺许可文本的包都由内部标记造成。

先比较生成条目与真实安装包：

npm ls vite socket.io-client engine.io-client engine.io-parser

再查看该模块实际落到哪个文件，以及那个文件向上到包根之间的 package.json。需要区分真实 node_modules 包根与包内部用来声明模块类型的目录。不要直接删除内部标记，它可能决定 .js 文件如何被解释，会影响正常加载。

Vite 8.3.4 的正式代码会在 node_modules 中继续越过不是实际包根的内部标记，再取得包级元数据。若项目可以迁移到这个已包含处理的版本，可在分支进行：

npm install -D vite@8.3.4
npm ls vite
npm run build

升级 Vite 主版本前，仍要核对 Node 与插件支持范围；7.x 项目不能只替换版本号而跳过迁移验收。这里不把 8.3.4 称为这项问题的全球首次修复版。

保留原本的 license 配置，例如：

import { defineConfig } from 'vite';
export default defineConfig({
  build: {
    license: { fileName: 'license.md' },
  },
});

重新构建后，对照输出中的依赖版本与实际包根版本，检查许可标识及包提供的许可正文是否被正确读入。socket.io-client 的例子还需逐项检查传递依赖，不能只看最外层包恢复就认为每条记录都完整。

若真实包根本身没有版本或许可信息，正确找到包根也不会凭空生成它；应进一步检查包内容、发布元数据与输出配置。0.0.0 消失也不等于项目已满足所有授权义务，这里验收的是构建元数据归属与读取结果，不能把生成器的一份文件当成完整法律结论。