尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

深入理解 Vite 许可文件:MIT 核心与打包依赖双层披露结构及其自动生成机制

深入理解 Vite 许可文件:MIT 核心与打包依赖双层披露结构及其自动生成机制 深入理解 Vite 许可文件MIT 核心与打包依赖双层披露结构及其自动生成机制【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/viteVite 的 packages/vite/LICENSE.md 是理解该项目许可体系的核心文档它由“Vite 核心 MIT 许可”与“发布产物中打包的第三方依赖许可”两层构成完整披露了约 103 个 npm 包的五类许可文本。读完本文你将掌握这份文件的结构与合规含义、为什么 Vite 需要单独披露打包依赖以及如何从源码层面理解这份文件是由构建管道自动生成和维持更新的机制。一、LICENSE.md 的双层结构打开 packages/vite/LICENSE.md文件分为三个层次Vite 核心许可MIT 许可全文声明 Vite 本体的版权与授权条款打包依赖许可摘要一句话列出发布产物中额外包含代码的许可类型——Apache-2.0, BSD-2-Clause, CC0-1.0, ISC, MIT打包依赖清单Bundled dependencies按包分组列出每个或每组依赖的许可类型、作者与许可全文引用。这种结构不是手写的产物——后文会展示它是由 Vite 的构建插件在每次打包时自动重算生成的。这也解释了为什么清单会随版本迭代当前仓库版本为vite8.2.2见 packages/vite/package.json而增减。第一层Vite 核心的 MIT 许可文件开篇即给出核心许可声明Vite core licenseVite is released under the MIT license:MIT LicenseCopyright (c) 2019-present, VoidZero Inc. and Vite contributorsPermission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.这段文字与仓库根目录的 LICENSE 文件逐字一致——自动生成逻辑会直接读取根目录许可文本见 packages/vite/rollupLicensePlugin.ts 中new URL(../../LICENSE, import.meta.url)的读取路径。逐条拆解 MIT 条款的要点条款内容对使用者的意义版权Copyright (c) 2019-present, VoidZero Inc. and Vite contributors版权归 VoidZero 公司与全部贡献者共有授权免费获得使用、复制、修改、合并、发布、分发、再许可、出售副本的权利商用、闭源分发均被允许无需付费唯一条件所有副本或实质性部分中必须包含上述版权声明与本许可声明再分发 Vite 代码时须保留许可文本免责声明软件按“AS IS”提供不附带任何明示或暗示担保作者不对商用品质、适用性担责责任限制在任何情况下作者或版权持有人均不赔偿任何损失使用风险由使用者自担package.json 中的license: MIT字段packages/vite/package.json与之一致同仓库的官方插件包 packages/plugin-legacy/package.json 同样声明 MIT并配有独立的 LICENSE 文件可作为编写 Vite 插件时的许可声明范式。第二层打包依赖的五类许可文档第二层声明“The published Vite artifact additionally contains code with the following licenses: Apache-2.0, BSD-2-Clause, CC0-1.0, ISC, MIT”。为什么要单独披露因为 Vite 发布的 npm 包files字段包含bin、dist、misc、client.d.ts、types见 packages/vite/package.json中dist/下的大多数运行时模块是将 devDependencies 直接打包bundle进产物的。从构建配置 packages/vite/rolldown.config.ts 可以看到仅pkg.dependencieslightningcss、picomatch、postcss、rolldown、tinyglobby等被列为external而 chokidar、connect、cors、ws、es-module-lexer、postcss-import 等数十个包虽声明在devDependencies中却被打进dist/node/*.js。既然发布产物内含这些第三方代码就必须按各自许可条款做出披露——这就是这份 LICENSE.md 存在的原因。各许可类型的性质与在文档中的代表包许可类型性质文档中列出的依赖节选MIT约 90 包宽松型保留版权声明即可chokidar、connect、cors、ws、magic-string、es-module-lexer、parse5、sirv、cac、postcss-import 等ISC9 包宽松型条款与 MIT 近似anymatch、glob-parent、picocolors、isexe、which、icss-utils、postcss-modules-scope 等BSD-2-Clause2 包宽松型要求源码/二进制再分发保留声明dotenv-expand、entitiesApache-2.01 包宽松型额外含专利授权与 NOTICE 保留要求vercel/detect-agentCC0-1.01 包公有领域奉献几乎无限制string-hash完整清单按文档原分组组内多个包共享同一份许可文本这正是自动生成器的合并规则后文详述MITjridgewell/gen-mapping、jridgewell/remapping、jridgewell/sourcemap-codec、jridgewell/trace-mapping、jridgewell/resolve-uri、polka/compression、polka/url、rollup/plugin-alias、rollup/plugin-dynamic-import-vars、rollup/pluginutils、vitest/utils、voidzero-dev/vite-task-client、artichokie、binary-extensions、braces、fill-range、is-number、bundle-name、default-browser、default-browser-id、define-lazy-prop、is-docker、is-inside-container、is-wsl、open、run-applescript、wsl-utils、cac、chokidar、connect、convert-source-map、cors、cross-spawn、cssesc、ee-first、encodeurl、es-module-lexer、escape-html、estree-walker、etag、finalhandler、follow-redirects、fresh-import、generic-names、host-validation-middleware、http-proxy-3、is-binary-path、is-extglob、is-glob、is-reference、js-tokens、launch-editor、launch-editor-middleware、lilconfig、loader-utils、lodash.camelcase、magic-string、mlly、ufo、mrmime、normalize-path、object-assign、obug、on-finished、parse5、parseurl、path-key、shebang-regex、periscopic、postcss-import、postcss-load-config、postcss-modules、postcss-modules-local-by-default、postcss-selector-parser、postcss-value-parser、readdirp、resolve.exports、totalist、shebang-command、shell-quote、sirv、statuses、strip-literal、to-regex-range、unpipe、util-deprecate、utils-merge、vary、ws、zimmerframeISCanymatch、glob-parent、icss-utils、isexe、which、picocolors、postcss-modules-extract-imports、postcss-modules-scope、postcss-modules-valuesBSD-2-Clausedotenv-expand、entitiesApache-2.0vercel/detect-agent文档中完整收录了 Apache 2.0 全文含专利授权、重分发须附许可副本与 NOTICE、商标限制等九节条款CC0-1.0string-hash。对使用者的实际含义全部五类许可均为宽松型/公有领域许可与 MIT 无冲突可以在同一商业项目中混合使用Vite 官方已通过这份文件完成了对打包代码的署名与条款披露你只需在再分发 Vite 构建产物时随附该文件即可。二、自动生成机制构建时的 rollupLicensePlugin这份 2300 余行的文档并非人工维护。在构建配置 packages/vite/rolldown.config.ts 中node 端打包index、cli、internal三个入口挂载了如下插件licensePlugin( path.resolve(dirname, LICENSE.md), Vite core license, Vite, ),对应实现位于 packages/vite/rollupLicensePlugin.ts。其核心是一个thirdParty(dependencies)回调L13-L117在打包生成 bundle 后由rollup-plugin-license触发流程如下读取核心许可从仓库根目录读入 LICENSE 全文作为“Vite core license”章节的内容L17-L20排序与许可类型汇总依赖按名称排序sortDependenciesL130-L134并收集所有许可类型去重排序无括号的排前见sortLicenses生成“additionally contains code with the following licenses”那一行同许可文本合并遍历依赖时若多个包的licenseText逐字相同例如一批 Sindre Sorhus 或 Jon Schlinkert 的包都使用标准 MIT 模板会被合并进同一个##小节表头写成## braces, fill-range, is-number这种并列形式——这正解释了文档中为何会出现多包共享一节的现象L30-L43作者信息归并从每个包的author、maintainers、contributors字段去重收集姓名生成By:行若同组依赖的许可与作者完全一致信息只展示一次L46-L64仓库地址规范化normalizeGitUrlL185-L204把git、ssh://、github:等各种写法统一转换为https://形式的仓库地址即文档中每个依赖的Repository:行许可全文引用化每份许可全文逐行加前缀以引用块形式嵌入L77-L87并统一换行符为\n小节之间以-------分隔线隔开差异写盘与提醒将拼装结果与磁盘上现有的 LICENSE.md 对比只有内容变化时才写入并打印黄色警告 “LICENSE.md updated. You should commit the updated file.”L108-L116。也就是说这份文件要求维护者在依赖变动后把自动生成的更新一并提交跳过 watch 模式插件对renderChunk、generateBundle两个钩子做了包装在this.meta.watchMode为真时直接跳过L119-L126避免开发调试时反复改写文件。因此完整的生成链路是pnpm buildpackage.json 脚本buildpremove dist pnpm build-bundle pnpm build-types→build-bundle执行rolldown --config rolldown.config.ts→ node 端打包触发 license 插件 → 重算 packages/vite/LICENSE.md。这解释了为什么文档中的依赖清单与devDependencies列表高度重合且随版本迭代变化。三、对使用者与二次开发者的合规要点结合本文档与仓库结构可以得出几点实操结论均以当前仓库内容为准直接安装使用 Vitenpm i vite产物按 MIT 授权可自由用于商业项目发布产物自带 LICENSE.md 披露无需额外动作。运行前提按 packages/vite/package.json 为 Node^20.19.0 || 22.12.0。再分发或 fork Vite 构建产物保留 LICENSE.md或至少其中的核心版权声明与许可文本即满足 MIT 的唯一条件对 Apache-2.0 的 vercel/detect-agent 部分按条款需随分发附带 Apache 许可副本。编写 Vite 插件参照官方vitejs/plugin-legacy的做法——package.json中声明license: MIT并在包目录内附 LICENSE 文件见 packages/plugin-legacy/package.json 与 packages/plugin-legacy/LICENSE。从源码构建 Vite执行构建后若控制台出现 “LICENSE.md updated. You should commit the updated file.” 警告说明打包依赖的许可发生了变化应检查自动生成的 LICENSE.md diff 后提交而不是忽略它。四、关键路径速查路径内容LICENSE仓库根目录 MIT 许可全文核心许可文本的唯一来源packages/vite/LICENSE.md发布产物的双层许可披露文档自动生成packages/vite/rollupLicensePlugin.ts许可文档自动生成插件实现packages/vite/rolldown.config.ts构建配置中挂载 license 插件的位置packages/vite/package.jsonlicense字段、files发布清单、依赖划分packages/plugin-legacy/package.json官方插件包的 MIT 许可声明示例CONTRIBUTING.md贡献者规范含依赖划分约定总结Vite 的许可体系是“MIT 核心 打包依赖自动披露”的双层结构。核心代码的宽松授权保证了自由使用而由构建管道自动维护的依赖披露packages/vite/LICENSE.md则让发布产物中实际包含的每一段第三方代码都有据可查。理解这套机制后无论是评估商用合规、fork 定制还是开发自己的插件都能快速定位到准确的授权依据。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表