Vite 致谢页全解析依赖鸣谢清单如何由 LICENSE.md 与 package.json 自动生成【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/viteVite 官方文档中的致谢页Acknowledgements并不是一份人工维护的静态名单——页面上的依赖包、作者与赞助信息全部由 VitePress 数据加载器在构建时从仓库文件自动读取和聚合。本文沿这条完整的许可证汇总 → LICENSE.md → 致谢页流水线逐环节展开并解释 Vite 绝大多数依赖放入 devDependencies 再预打包的依赖策略帮助你在阅读这份鸣谢清单的同时理解 Vite 核心包是如何保持轻量的。一、致谢页包含什么人、资金与包的完整清单致谢页的页面结构由四个板块组成这也是本文的骨架Contributors贡献者Vite 由一个国际化团队开发核心成员见团队页同时鸣谢所有通过代码、Bug 报告、文档及文档翻译帮助改进 Vite 的贡献者。Sponsors赞助者页面通过 VitePress 主题提供的useSponsor可组合函数和VPSponsors组件动态渲染赞助商列表支持渠道为 GitHub Sponsors 与 Open Collective。Dependencies依赖又分两部分——Notable Dependencies重点依赖以卡片形式展示作者、描述与仓库/赞助链接和Bundled Dependency Authors被打包进发行产物的依赖的作者汇总表按作者归组。Development Tools开发工具支撑 Vite 自身开发工作流的工具清单。Past Notable Dependencies历史重点依赖记录 Vite 早期版本使用、如今已被替换的项目。页面本身只是展示层docs/acknowledgements.md 中大量使用v-for循环渲染数据数组真正决定页面内容的是下一节的数据源文件。二、数据源一个构建期读取 node_modules 的 VitePress 数据加载器致谢页所有动态数据来自 docs/_data/acknowledgements.data.ts。这个文件是一个标准的 VitePress data loader导出{ watch, load }构建文档时执行其工作分三步1. 静态名单 解析 LICENSE.md 得到被打包依赖全集。文件开头硬编码了三份名单acknowledgements.data.ts#L5-L20// Notable dependencies to highlight (by package name) const notableDependencies [ rolldown, postcss, lightningcss, chokidar, magic-string, ] // Dev tools used for development const devToolNames [ eslint, oxfmt, typescript, vitest, playwright-chromium, ]而Bundled dependencies并不在这里写死而是由parseBundledDependenciesFromLicense()acknowledgements.data.ts#L113-L126从 packages/vite/LICENSE.md 中解析const bundledSection content.split(# Bundled dependencies:\n)[1] // Match all ## headers which contain package names (comma-separated for grouped packages) const deps [...bundledSection.matchAll(/^## (.)$/gm)].flatMap((m) m[1].split(,).map((n) n.trim()), )注意split(,)这一步LICENSE.md 中的##标题可能是pkg1, pkg2, pkg3这样的逗号分组形式例如当前的## braces, fill-range, is-number、## mlly, ufo解析器必须按逗号拆开才能还原出真实包名——这个细节与第三节 LICENSE.md 的生成逻辑严格对应。2. 逐包读取 node_modules 中的 package.json。readPackageInfo()acknowledgements.data.ts#L195-L219依次尝试packages/vite/node_modules/name/package.json和仓库根node_modules/name/package.json提取name、version、description、author、repository、funding字段。包不存在时返回null并被过滤——注释说明原因某些包可能只是可选 peer 依赖并未真正安装。配套的两个归一化函数覆盖了 npm 元数据的各种方言normalizeRepository()acknowledgements.data.ts#L128-L159将githttps://...、ssh://userhost.com:org/repo.git、github:org/repo、gitlab:、bitbucket:以及裸的owner/repo等形式统一成可用的 HTTPS 链接parseAuthor()同时支持对象形式和字符串形式Name email (url)拆出姓名与个人主页normalizeFunding()funding字段无论是字符串、对象还是数组统一取第一个 URL。3. 按作者归组生成Bundled Dependency Authors表。groupByAuthor()acknowledgements.data.ts#L221-L264把非重点的打包依赖bundledDependencies中排除掉notableDependencies后的部分按author字段分桶包名与作者均按字母序排序。有一个展示层面的优化若某作者名下所有包的fundingURL 完全一致则把赞助链接提升到作者级别包列表里就不再逐个重复显示 Sponsor 按钮。最后loader 通过watch: [../../packages/vite/LICENSE.md]acknowledgements.data.ts#L314-L319声明了对 LICENSE.md 的监听——依赖集合变化导致 LICENSE.md 重新生成后文档构建会自动重建该页数据整个链路因此是自我同步的。三、流水线上游LICENSE.md 本身是构建时自动生成的packages/vite/LICENSE.md并非手写。它的生成逻辑在 packages/vite/rollupLicensePlugin.ts一个包装rollup-plugin-license的thirdParty钩子的构建插件做四件事读取核心许可证以仓库根 LICENSEMIT作为 Vite core license 段落写入文件开头排序与分组rollupLicensePlugin.ts#L22-L43依赖按名称排序许可证全文相同的依赖被合并成一个## pkg1, pkg2, pkg3分组标题——这正是第二节数据加载器要按逗号切分的来源。若同组依赖的许可证与作者也完全一致License:/By:/Repositories:元信息只打印一次输出汇总在# Licenses of bundled dependencies段落中列出产物包含的全部许可证类型当前为 Apache-2.0、BSD-2-Clause、CC0-1.0、ISC、MIT随后是# Bundled dependencies:明细区落盘并提醒提交rollupLicensePlugin.ts#L108-L116只有内容变化时才写回LICENSE.md并在终端打印黄色警告 LICENSE.md updated. You should commit the updated file.。插件还覆盖了renderChunk/generateBundle钩子在 watch 模式下直接跳过避免开发期反复写文件。该插件挂载在 packages/vite/rolldown.config.ts 的nodeConfig上rolldown.config.ts#L134-L138plugins: [ shimDepsPlugin({ /* ... */ }), buildTimeImportMetaUrlPlugin(), licensePlugin( path.resolve(dirname, LICENSE.md), Vite core license, Vite, ), // ... ]这个nodeConfig打包src/node/index.ts、src/node/cli.ts、src/node/internalIndex.ts三个入口并把pkg.dependencies与pkg.peerDependencies的全部键名标记为externalrolldown.config.ts#L86-L99——也就是说真正被内联进 dist 的只有 devDependencies而rollup-plugin-license在生成报告时恰好只统计实际被打包进来的依赖于是 LICENSE.md 的内容就精确等于发行产物中包含的第三方代码致谢页也因此得名 Bundled dependencies。四、为什么有这么多Bundled DependenciesVite 的依赖瘦身策略packages/vite/package.json 末尾有这样一条注释堪称理解致谢页的前提//: READ CONTRIBUTING.md to understand what to put under deps vs. devDeps!CONTRIBUTING.md 的 Notes on Dependencies 一节给出了完整规则目标Vite 追求轻量包括对 npm 依赖数量和体积的敏感核心机制We use Rolldown to pre-bundle most dependencies before publishing——发布前用 Rolldown 把大部分依赖预打包进产物因此即使某个依赖在运行时源码中被使用默认也应放进devDependencies例外必须进dependencies的情况类型包types/*含二进制文件无法被打包的依赖如rolldown、lightningcss其自带类型会出现在 Vite 公开类型中的依赖如rolldown约束由于 devDependencies 打包后从产物中消失源码中不能用普通require(somedep)ESM 中会被忽略、发布后也找不到而要写成(await import(somedep)).default的懒加载形式兼顾启动性能与打包正确性体积纪律CONTRIBUTING 举了一个真实案例——http-proxy本身约 380 kB而http-proxy-middleware会拖入约 3 MB 的传递依赖相比之下在http-proxy之上写几行自定义中间件即可这也是 Vite 选择自研中间件的原因。对照 packages/vite/package.json#L71-L77 可以看到策略的实际结果——vite 的运行时dependencies只有 5 个dependencies: { lightningcss: ^1.33.0, picomatch: ^4.0.7, postcss: ^8.5.26, rolldown: ~1.2.6, tinyglobby: ^0.2.17 }外加optionalDependencies中的fseventsmacOS 原生监听。而devDependencies里则躺着chokidar、magic-string、es-module-lexer、sirv、connect等三十多个运行时也用的包——它们全部会被打进dist/node并因此出现在 LICENSE.md 与致谢页中。类型方面还有一个配套机制为了让 Vite 能在 TypeScript 项目中被完整引用例如供 VitePress 使用需要把部分依赖的类型内联到packages/vite/src/types然后用pnpm run build-types-check校验打包后的类型不依赖任何 devDependencies。此外rolldown.config.ts 中还有一个bundleSizeLimit(55)插件rolldown.config.ts#L388-L416当module-runner产物超过约 55 kB 时直接令构建失败——轻量在这里是硬约束不只是口号。五、Notable Dependencies 与开发工具数据文件中的两份静态名单对应页面两组卡片Notable Dependenciesrolldown、postcss、lightningcss、chokidar、magic-string。它们在源码中的位置可以从 import 关系直接印证rolldown是当前 Vite 的构建与转换引擎从 optimizer/scan.ts、optimizer/index.ts依赖预构建到 build.ts、pluginContainer.ts、hmr.ts 等几十个核心模块都直接从rolldown导入插件与类型magic-string用于精确的源码改写Vite 自己的构建配置就用它实现shimDepsPlugin与buildTimeImportMetaUrlPluginrolldown.config.ts#L229-L299postcss是 CSS 处理管线核心配合postcss-import、postcss-load-config、postcss-modules等均在 devDependencies 中打包时通过shimDepsPlugin剔除冗余 import见 rolldown.config.ts#L101-L132 的注释lightningcss用于 CSS 压缩等原生加速路径chokidar是文件监听基础仓库根 patches/ 目录中还维护着chokidar3.6.0.patch等 pnpm patch说明 Vite 会直接修补依赖行为而非整体替换。Development Toolseslint、oxfmt、typescript、vitest、playwright-chromium与根 package.json 的 devDependencies 一一对应。仓库脚本体现了它们的分工pnpm linteslint 9 typescript-eslint、pnpm formatoxfmt同时由lint-staged在 pre-commit 时执行、pnpm typechecktsc 多项目配置、pnpm testvitest 单元测试 基于 Playwright 的test-serve/test-build集成测试测试目标即 playground/ 下上百个场景目录、pnpm docsVitePress 构建本文所在文档站。六、Past Notable Dependencies一份引擎演进的对照记录acknowledgements.data.ts#L23-L55 中的pastNotableDependencies列出了 Vite 曾经依赖、如今已替换或移除的六个项目其replacement 备注恰好勾勒出 Vite 底层的演进轨迹包用途现状据数据文件备注与 package.json 印证esbuildJS/TS 打包与压缩描述为 now using Rolldown, Oxc, and LightningCSS但 esbuild 仍保留为可选 peerDependency 与 devDependency^0.27.0 \|\| ^0.28.0/^0.28.2部分转换路径仍可能需要用户安装rollupESM 打包器now using Rolldownrollup仍留在 devDependencies^4.59.0主要服务于构建工具链生态如许可证插件rollup-plugin-license其类型即来自rolluphttp-proxyHTTP 代理now using http-proxy-3对应 devDependencies 中的http-proxy-3: ^1.23.3acornJavaScript 解析器已从依赖中移除解析能力由 Oxc 体系承接可参见 plugins/oxc.ts 的存在fast-glob快速 glob 匹配now using tinyglobby/fdir对应运行时依赖tinyglobby: ^0.2.17debug调试日志now using obug对应 devDependencies 中的obug: ^1.0.2从源码结构看Rolldown 取代 esbuild/rollup这一迁移已完成度很高vite 的构建入口、模块图、HMR、SSR 转换等核心模块均直接面向rolldown的插件 API 编写而不再经由 esbuild 或 rollup 中转。七、给包作者的提示你的 package.json 元数据决定你在致谢页的样子原文档中有一个面向第三方包作者的说明值得单独强调This section is automatically generated from theauthorandfundingfields in each packagespackage.json. If youd like to update how your package appears here, you can update these fields in your package.结合第二节的解析逻辑其含义非常具体如果你的包出现在 vite 的devDependencies中、被预打包进了dist/node从而进入 LICENSE.md 的# Bundled dependencies:区那么该包在package.json中声明的author支持对象或Name email (url)字符串将决定它是否以及以谁的名义出现在 Bundled Dependency Authors 表中funding字段字符串、对象或数组的第一个 URL则决定作者行/包名旁是否出现 Sponsor 链接repository字段会被normalizeRepository()归一化后展示。换言之更新你所在包的author与funding字段就是更新它在 Vite 致谢页呈现方式的唯一途径——而 Vite 侧的整条链路构建生成 LICENSE.md → 数据加载器解析 → 页面渲染无需任何人工介入。小结Vite 的致谢页看似一份静态鸣谢名单实际是一条完整的自动化管线构建时rollupLicensePlugin将预打包依赖的许可证汇总写入 LICENSE.md文档构建时 acknowledgements.data.ts 再解析该文件并结合 node_modules 中的package.json元数据生成卡片与作者表。这条管线背后是 Vite 运行时依赖仅 5 个、其余全部预打包的依赖纪律CONTRIBUTING.md与对产物体积的硬约束。理解这套机制后你可以把致谢页当作观察 Vite 依赖演进的窗口——包括 esbuild 到 Rolldown、http-proxy 到 http-proxy-3 这样已经落地的替换。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Vite 致谢页全解析：依赖鸣谢清单如何由 LICENSE.md 与 package.json 自动生成
Vite 致谢页全解析依赖鸣谢清单如何由 LICENSE.md 与 package.json 自动生成【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/viteVite 官方文档中的致谢页Acknowledgements并不是一份人工维护的静态名单——页面上的依赖包、作者与赞助信息全部由 VitePress 数据加载器在构建时从仓库文件自动读取和聚合。本文沿这条完整的许可证汇总 → LICENSE.md → 致谢页流水线逐环节展开并解释 Vite 绝大多数依赖放入 devDependencies 再预打包的依赖策略帮助你在阅读这份鸣谢清单的同时理解 Vite 核心包是如何保持轻量的。一、致谢页包含什么人、资金与包的完整清单致谢页的页面结构由四个板块组成这也是本文的骨架Contributors贡献者Vite 由一个国际化团队开发核心成员见团队页同时鸣谢所有通过代码、Bug 报告、文档及文档翻译帮助改进 Vite 的贡献者。Sponsors赞助者页面通过 VitePress 主题提供的useSponsor可组合函数和VPSponsors组件动态渲染赞助商列表支持渠道为 GitHub Sponsors 与 Open Collective。Dependencies依赖又分两部分——Notable Dependencies重点依赖以卡片形式展示作者、描述与仓库/赞助链接和Bundled Dependency Authors被打包进发行产物的依赖的作者汇总表按作者归组。Development Tools开发工具支撑 Vite 自身开发工作流的工具清单。Past Notable Dependencies历史重点依赖记录 Vite 早期版本使用、如今已被替换的项目。页面本身只是展示层docs/acknowledgements.md 中大量使用v-for循环渲染数据数组真正决定页面内容的是下一节的数据源文件。二、数据源一个构建期读取 node_modules 的 VitePress 数据加载器致谢页所有动态数据来自 docs/_data/acknowledgements.data.ts。这个文件是一个标准的 VitePress data loader导出{ watch, load }构建文档时执行其工作分三步1. 静态名单 解析 LICENSE.md 得到被打包依赖全集。文件开头硬编码了三份名单acknowledgements.data.ts#L5-L20// Notable dependencies to highlight (by package name) const notableDependencies [ rolldown, postcss, lightningcss, chokidar, magic-string, ] // Dev tools used for development const devToolNames [ eslint, oxfmt, typescript, vitest, playwright-chromium, ]而Bundled dependencies并不在这里写死而是由parseBundledDependenciesFromLicense()acknowledgements.data.ts#L113-L126从 packages/vite/LICENSE.md 中解析const bundledSection content.split(# Bundled dependencies:\n)[1] // Match all ## headers which contain package names (comma-separated for grouped packages) const deps [...bundledSection.matchAll(/^## (.)$/gm)].flatMap((m) m[1].split(,).map((n) n.trim()), )注意split(,)这一步LICENSE.md 中的##标题可能是pkg1, pkg2, pkg3这样的逗号分组形式例如当前的## braces, fill-range, is-number、## mlly, ufo解析器必须按逗号拆开才能还原出真实包名——这个细节与第三节 LICENSE.md 的生成逻辑严格对应。2. 逐包读取 node_modules 中的 package.json。readPackageInfo()acknowledgements.data.ts#L195-L219依次尝试packages/vite/node_modules/name/package.json和仓库根node_modules/name/package.json提取name、version、description、author、repository、funding字段。包不存在时返回null并被过滤——注释说明原因某些包可能只是可选 peer 依赖并未真正安装。配套的两个归一化函数覆盖了 npm 元数据的各种方言normalizeRepository()acknowledgements.data.ts#L128-L159将githttps://...、ssh://userhost.com:org/repo.git、github:org/repo、gitlab:、bitbucket:以及裸的owner/repo等形式统一成可用的 HTTPS 链接parseAuthor()同时支持对象形式和字符串形式Name email (url)拆出姓名与个人主页normalizeFunding()funding字段无论是字符串、对象还是数组统一取第一个 URL。3. 按作者归组生成Bundled Dependency Authors表。groupByAuthor()acknowledgements.data.ts#L221-L264把非重点的打包依赖bundledDependencies中排除掉notableDependencies后的部分按author字段分桶包名与作者均按字母序排序。有一个展示层面的优化若某作者名下所有包的fundingURL 完全一致则把赞助链接提升到作者级别包列表里就不再逐个重复显示 Sponsor 按钮。最后loader 通过watch: [../../packages/vite/LICENSE.md]acknowledgements.data.ts#L314-L319声明了对 LICENSE.md 的监听——依赖集合变化导致 LICENSE.md 重新生成后文档构建会自动重建该页数据整个链路因此是自我同步的。三、流水线上游LICENSE.md 本身是构建时自动生成的packages/vite/LICENSE.md并非手写。它的生成逻辑在 packages/vite/rollupLicensePlugin.ts一个包装rollup-plugin-license的thirdParty钩子的构建插件做四件事读取核心许可证以仓库根 LICENSEMIT作为 Vite core license 段落写入文件开头排序与分组rollupLicensePlugin.ts#L22-L43依赖按名称排序许可证全文相同的依赖被合并成一个## pkg1, pkg2, pkg3分组标题——这正是第二节数据加载器要按逗号切分的来源。若同组依赖的许可证与作者也完全一致License:/By:/Repositories:元信息只打印一次输出汇总在# Licenses of bundled dependencies段落中列出产物包含的全部许可证类型当前为 Apache-2.0、BSD-2-Clause、CC0-1.0、ISC、MIT随后是# Bundled dependencies:明细区落盘并提醒提交rollupLicensePlugin.ts#L108-L116只有内容变化时才写回LICENSE.md并在终端打印黄色警告 LICENSE.md updated. You should commit the updated file.。插件还覆盖了renderChunk/generateBundle钩子在 watch 模式下直接跳过避免开发期反复写文件。该插件挂载在 packages/vite/rolldown.config.ts 的nodeConfig上rolldown.config.ts#L134-L138plugins: [ shimDepsPlugin({ /* ... */ }), buildTimeImportMetaUrlPlugin(), licensePlugin( path.resolve(dirname, LICENSE.md), Vite core license, Vite, ), // ... ]这个nodeConfig打包src/node/index.ts、src/node/cli.ts、src/node/internalIndex.ts三个入口并把pkg.dependencies与pkg.peerDependencies的全部键名标记为externalrolldown.config.ts#L86-L99——也就是说真正被内联进 dist 的只有 devDependencies而rollup-plugin-license在生成报告时恰好只统计实际被打包进来的依赖于是 LICENSE.md 的内容就精确等于发行产物中包含的第三方代码致谢页也因此得名 Bundled dependencies。四、为什么有这么多Bundled DependenciesVite 的依赖瘦身策略packages/vite/package.json 末尾有这样一条注释堪称理解致谢页的前提//: READ CONTRIBUTING.md to understand what to put under deps vs. devDeps!CONTRIBUTING.md 的 Notes on Dependencies 一节给出了完整规则目标Vite 追求轻量包括对 npm 依赖数量和体积的敏感核心机制We use Rolldown to pre-bundle most dependencies before publishing——发布前用 Rolldown 把大部分依赖预打包进产物因此即使某个依赖在运行时源码中被使用默认也应放进devDependencies例外必须进dependencies的情况类型包types/*含二进制文件无法被打包的依赖如rolldown、lightningcss其自带类型会出现在 Vite 公开类型中的依赖如rolldown约束由于 devDependencies 打包后从产物中消失源码中不能用普通require(somedep)ESM 中会被忽略、发布后也找不到而要写成(await import(somedep)).default的懒加载形式兼顾启动性能与打包正确性体积纪律CONTRIBUTING 举了一个真实案例——http-proxy本身约 380 kB而http-proxy-middleware会拖入约 3 MB 的传递依赖相比之下在http-proxy之上写几行自定义中间件即可这也是 Vite 选择自研中间件的原因。对照 packages/vite/package.json#L71-L77 可以看到策略的实际结果——vite 的运行时dependencies只有 5 个dependencies: { lightningcss: ^1.33.0, picomatch: ^4.0.7, postcss: ^8.5.26, rolldown: ~1.2.6, tinyglobby: ^0.2.17 }外加optionalDependencies中的fseventsmacOS 原生监听。而devDependencies里则躺着chokidar、magic-string、es-module-lexer、sirv、connect等三十多个运行时也用的包——它们全部会被打进dist/node并因此出现在 LICENSE.md 与致谢页中。类型方面还有一个配套机制为了让 Vite 能在 TypeScript 项目中被完整引用例如供 VitePress 使用需要把部分依赖的类型内联到packages/vite/src/types然后用pnpm run build-types-check校验打包后的类型不依赖任何 devDependencies。此外rolldown.config.ts 中还有一个bundleSizeLimit(55)插件rolldown.config.ts#L388-L416当module-runner产物超过约 55 kB 时直接令构建失败——轻量在这里是硬约束不只是口号。五、Notable Dependencies 与开发工具数据文件中的两份静态名单对应页面两组卡片Notable Dependenciesrolldown、postcss、lightningcss、chokidar、magic-string。它们在源码中的位置可以从 import 关系直接印证rolldown是当前 Vite 的构建与转换引擎从 optimizer/scan.ts、optimizer/index.ts依赖预构建到 build.ts、pluginContainer.ts、hmr.ts 等几十个核心模块都直接从rolldown导入插件与类型magic-string用于精确的源码改写Vite 自己的构建配置就用它实现shimDepsPlugin与buildTimeImportMetaUrlPluginrolldown.config.ts#L229-L299postcss是 CSS 处理管线核心配合postcss-import、postcss-load-config、postcss-modules等均在 devDependencies 中打包时通过shimDepsPlugin剔除冗余 import见 rolldown.config.ts#L101-L132 的注释lightningcss用于 CSS 压缩等原生加速路径chokidar是文件监听基础仓库根 patches/ 目录中还维护着chokidar3.6.0.patch等 pnpm patch说明 Vite 会直接修补依赖行为而非整体替换。Development Toolseslint、oxfmt、typescript、vitest、playwright-chromium与根 package.json 的 devDependencies 一一对应。仓库脚本体现了它们的分工pnpm linteslint 9 typescript-eslint、pnpm formatoxfmt同时由lint-staged在 pre-commit 时执行、pnpm typechecktsc 多项目配置、pnpm testvitest 单元测试 基于 Playwright 的test-serve/test-build集成测试测试目标即 playground/ 下上百个场景目录、pnpm docsVitePress 构建本文所在文档站。六、Past Notable Dependencies一份引擎演进的对照记录acknowledgements.data.ts#L23-L55 中的pastNotableDependencies列出了 Vite 曾经依赖、如今已替换或移除的六个项目其replacement 备注恰好勾勒出 Vite 底层的演进轨迹包用途现状据数据文件备注与 package.json 印证esbuildJS/TS 打包与压缩描述为 now using Rolldown, Oxc, and LightningCSS但 esbuild 仍保留为可选 peerDependency 与 devDependency^0.27.0 \|\| ^0.28.0/^0.28.2部分转换路径仍可能需要用户安装rollupESM 打包器now using Rolldownrollup仍留在 devDependencies^4.59.0主要服务于构建工具链生态如许可证插件rollup-plugin-license其类型即来自rolluphttp-proxyHTTP 代理now using http-proxy-3对应 devDependencies 中的http-proxy-3: ^1.23.3acornJavaScript 解析器已从依赖中移除解析能力由 Oxc 体系承接可参见 plugins/oxc.ts 的存在fast-glob快速 glob 匹配now using tinyglobby/fdir对应运行时依赖tinyglobby: ^0.2.17debug调试日志now using obug对应 devDependencies 中的obug: ^1.0.2从源码结构看Rolldown 取代 esbuild/rollup这一迁移已完成度很高vite 的构建入口、模块图、HMR、SSR 转换等核心模块均直接面向rolldown的插件 API 编写而不再经由 esbuild 或 rollup 中转。七、给包作者的提示你的 package.json 元数据决定你在致谢页的样子原文档中有一个面向第三方包作者的说明值得单独强调This section is automatically generated from theauthorandfundingfields in each packagespackage.json. If youd like to update how your package appears here, you can update these fields in your package.结合第二节的解析逻辑其含义非常具体如果你的包出现在 vite 的devDependencies中、被预打包进了dist/node从而进入 LICENSE.md 的# Bundled dependencies:区那么该包在package.json中声明的author支持对象或Name email (url)字符串将决定它是否以及以谁的名义出现在 Bundled Dependency Authors 表中funding字段字符串、对象或数组的第一个 URL则决定作者行/包名旁是否出现 Sponsor 链接repository字段会被normalizeRepository()归一化后展示。换言之更新你所在包的author与funding字段就是更新它在 Vite 致谢页呈现方式的唯一途径——而 Vite 侧的整条链路构建生成 LICENSE.md → 数据加载器解析 → 页面渲染无需任何人工介入。小结Vite 的致谢页看似一份静态鸣谢名单实际是一条完整的自动化管线构建时rollupLicensePlugin将预打包依赖的许可证汇总写入 LICENSE.md文档构建时 acknowledgements.data.ts 再解析该文件并结合 node_modules 中的package.json元数据生成卡片与作者表。这条管线背后是 Vite 运行时依赖仅 5 个、其余全部预打包的依赖纪律CONTRIBUTING.md与对产物体积的硬约束。理解这套机制后你可以把致谢页当作观察 Vite 依赖演进的窗口——包括 esbuild 到 Rolldown、http-proxy 到 http-proxy-3 这样已经落地的替换。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
