发现于 #3664 的实施(PR #3695)做兄弟包 License 形态普查时。不在该单完成范围内,单独记录。
事实(origin/main be9cd38ac)
38 个已发布(非 private)包里,36 个有 LICENSE 文件,2 个没有:
| 包 |
version |
private |
license 字段 |
files |
LICENSE 文件 |
README 文件 |
@object-ui/react-runtime |
17.3.0 |
否(会发布) |
MIT |
["dist"] |
无 |
有 |
@object-ui/sdui-parser |
17.3.0 |
否(会发布) |
MIT |
["dist"] |
无 |
无 |
两个包的 package.json 都写着 "license": "MIT",但仓库里没有对应的许可证文本,因此已发布的 tarball 不含 MIT 要求随分发附带的许可证与版权声明。sdui-parser 另外还是 38 个已发布包里唯一连 README 都没有的。
这不是 files 声明问题,是文件本身不存在
值得写明,因为它决定了修法:npm 有一份无视 files 恒定打包的清单 —— package.json、README、LICENSE/LICENCE、以及 main 指向的文件。也就是说 files: ["dist"] 并不会把 LICENSE 排除在 tarball 之外;只要文件存在就会被带上。
所以这两个包缺许可证文本的原因是磁盘上根本没有该文件,不是 files 少写了一项。修法相应地是「补文件」,而不是「改 files」—— 改 files 加 "LICENSE" 是无效操作(另外 36 个包里有的写了这一项,有的没写,两种写法在 npm 侧等价)。
这与 #3647 的形态正相反,值得并排看:plugin-tree 是声明了 files 含 LICENSE、文件却不存在(声明失真,npm 对 files 里不存在的条目静默跳过);这两个是没作声明、文件也不存在。npm 的行为让两者殊途同归 —— tarball 都没有许可证文本。
与 #3647 的关系:这是它显式移交、却随关闭而落空的那个决定
#3647 正文把这两个包明确划出了自己的范围,并把它交给分诊:
react-runtime / sdui-parser 的 files 只有 dist,没有作出这个声明,所以它们是「策略问题」(要不要给所有已发布包补 LICENSE),不是「声明失真」。
最小修复是给 packages/plugin-tree 补一份……是否顺带统一 react-runtime / sdui-parser 的打包策略,请分诊裁决——那是另一个决定。
#3647 已于 2026-08-07 17:45 以 completed 关闭(PR #3662 只动了 packages/plugin-tree/LICENSE 一个文件),那个「另一个决定」没有落到任何单子上。按关键字(LICENSE、react-runtime、sdui-parser)与文件路径检索当前 open issues,除 #3664 外无覆盖此事的条目 —— 故独立立此条,而不是挂在已关闭的 #3647 下。
现有门禁为什么抓不到
三道相关门禁各自都是绿的,合起来仍留下这个缺口:
建议范围(未实施,含一个待裁决项)
事实层面无争议;要请维护者裁决的是范围:
倾向 B:A 修的是这一次的两个包,B 让第 39 个包加进来时不用靠人再普查一遍 —— 本条与 #3647 都是靠人肉逐包核对才发现的,连着两次说明缺的是门禁不是细心。但补 LICENSE 是否等于确认这两个包「应当继续作为公开发布物」,属于打包策略,交分诊。
相邻但不同、已另有归属的事
sdui-parser / react-runtime 的 files 只声明 dist 这件事本身(即打包内容是否完整)在 #3647 与 #3664 正文里都被称作「打包策略」问题。本条只主张其中许可证文本缺失这一个可证实的后果,不重复主张打包策略本身。
发现于 #3664 的实施(PR #3695)做兄弟包 License 形态普查时。不在该单完成范围内,单独记录。
事实(origin/main
be9cd38ac)38 个已发布(非
private)包里,36 个有LICENSE文件,2 个没有:privatelicense字段files@object-ui/react-runtimeMIT["dist"]@object-ui/sdui-parserMIT["dist"]两个包的
package.json都写着"license": "MIT",但仓库里没有对应的许可证文本,因此已发布的 tarball 不含 MIT 要求随分发附带的许可证与版权声明。sdui-parser另外还是 38 个已发布包里唯一连 README 都没有的。这不是
files声明问题,是文件本身不存在值得写明,因为它决定了修法:npm 有一份无视
files恒定打包的清单 ——package.json、README、LICENSE/LICENCE、以及main指向的文件。也就是说files: ["dist"]并不会把 LICENSE 排除在 tarball 之外;只要文件存在就会被带上。所以这两个包缺许可证文本的原因是磁盘上根本没有该文件,不是
files少写了一项。修法相应地是「补文件」,而不是「改files」—— 改files加"LICENSE"是无效操作(另外 36 个包里有的写了这一项,有的没写,两种写法在 npm 侧等价)。这与 #3647 的形态正相反,值得并排看:
plugin-tree是声明了files含 LICENSE、文件却不存在(声明失真,npm 对files里不存在的条目静默跳过);这两个是没作声明、文件也不存在。npm 的行为让两者殊途同归 —— tarball 都没有许可证文本。与 #3647 的关系:这是它显式移交、却随关闭而落空的那个决定
#3647 正文把这两个包明确划出了自己的范围,并把它交给分诊:
#3647 已于 2026-08-07 17:45 以
completed关闭(PR #3662 只动了packages/plugin-tree/LICENSE一个文件),那个「另一个决定」没有落到任何单子上。按关键字(LICENSE、react-runtime、sdui-parser)与文件路径检索当前 open issues,除 #3664 外无覆盖此事的条目 —— 故独立立此条,而不是挂在已关闭的 #3647 下。现有门禁为什么抓不到
三道相关门禁各自都是绿的,合起来仍留下这个缺口:
scripts/check-doc-links.mjs第 7 扫描根(packages/*/README.md,disk规则)只校验已经写出来的相对链接。这两个包的 README 里 License 一节写的是裸MIT(react-runtime),不含./LICENSE链接;sdui-parser没有 README。无链可死,与 packages/plugin-tree/README.md 是 38 个已发布包里唯一没有## License小节的 #3664 记录的 plugin-tree 是同一个盲区。files声明的条目必须在磁盘真实存在 (#3663) #3667 那道「package.json的files条目必须在磁盘上存在」的门禁,校验方向是files里写了的东西必须存在;这两个包没写LICENSE,自然无从触发。license字段与许可证文件是否一致,目前没有任何检查。建议范围(未实施,含一个待裁决项)
事实层面无争议;要请维护者裁决的是范围:
LICENSE的副本),使 38/38 齐平。顺带可给sdui-parser补 README(它是唯一没有的)。private且声明了license字段的包,必须存在 LICENSE 文件」。这会把本条、@object-ui/plugin-tree 的 package.json files 声明了 LICENSE,但 packages/plugin-tree/LICENSE 不存在——已发布包缺失它自己声明要带的许可证文本 #3647、以及将来新增包的同类漏洞一次性堵死,方向上与 没有门禁校验「package.json 的 files 条目在磁盘上真实存在」——npm 静默跳过缺失条目,#3647 因此长期无人察觉 #3663 的files-存在性门禁同源(那道是「声明了要带的必须存在」,这道是「声明了许可证的必须有文本」)。倾向 B:A 修的是这一次的两个包,B 让第 39 个包加进来时不用靠人再普查一遍 —— 本条与 #3647 都是靠人肉逐包核对才发现的,连着两次说明缺的是门禁不是细心。但补 LICENSE 是否等于确认这两个包「应当继续作为公开发布物」,属于打包策略,交分诊。
相邻但不同、已另有归属的事
sdui-parser/react-runtime的files只声明dist这件事本身(即打包内容是否完整)在 #3647 与 #3664 正文里都被称作「打包策略」问题。本条只主张其中许可证文本缺失这一个可证实的后果,不重复主张打包策略本身。