JavaScript 的美好未来不会实现
在经历了史上最大规模的供应链攻击之后，JavaScript社区本应迎来反思时刻，并作出决断：绝不再犯。当恐慌与羞愧逐渐平息，被入侵的开发者完成工作站重置与密钥轮换后，整个生态系统或许会重新聚焦于解决导致此次事件的根本缺陷。
毕竟多年来人们一直在敲响警钟，指出这种依赖管理方式鲁莽至极且危险的设计缺陷。或许此刻正是JavaScript生态系统开始认识到该问题的重要性和紧迫性，并着手修正方向的转折点。它可以摒弃那些充斥着微型库的庞杂依赖树，建立基于信任关系的软件分发体系，并吸纳更严谨的依赖管理系统数十年来积累的研究成果与创新实践。
或许谷歌和Mozilla——这两家在JavaScript标准制定与实现领域占据领导地位的公司——将着手开发真正的JavaScript标准库，让left-pad这类微依赖成为历史。此举可与整合工作相结合，将微型库合并为功能更完整、范围更统一的大型包，进而精简各自的依赖关系树。
这或许是npm正视其缺陷设计的关键时刻。凭借雄厚资金支持(需知npm母公司GitHub隶属微软，市值高达3万亿美元)，它将开发并推出新一代JavaScript包管理方案。新方案可借鉴Linux发行版经实践验证的成熟机制——通过解耦开发与打包分发流程，设立包维护者负责整合分发精选的软件库集合。引入可执行代码包的通用签名机制、小型化信任链、可复现构建流程，以及负责任的包管理器普遍采用的其他直观技术。
或许其他依赖于这种缺陷依赖管理模型的语言——如Cargo、PyPI、RubyGems等——正在关注此次事件，并意识到同样的危机正笼罩在它们的未来。或许在不可避免的危机降临之前，它们也会改变方向。
试想，倘若其他依赖并从这堆草率构建的庞大软件中获利的大型企业，能投入资金和资源来解决这些问题——让工程师们着手修复漏洞，联合制定并实施新标准，直接资助相关项目，并通过NLNet等机构分配资金——那么我们将迎来一个负责任、可持续且安全的软件开发时代。
这本是美好的未来图景，却非我们即将面对的现实。未来只会延续现状。我们只会看到象征性举措——强制双因素认证将在更多平台推行，巨头们也会在营销预算中以“开源安全与韧性”之名拨出微薄捐款。
无人会吸取教训。数十年来循环往复，至今无人从中获得启示。这正是当代软件开发领域最致命的傲慢。
本文文字及图片出自 A better future for JavaScript that won't happen
> 或许谷歌和Mozilla——这两家在JavaScript标准制定与实现领域占据领导地位的公司——将着手开发真正的JavaScript标准库，让left-pad这类微依赖成为历史。
这种观点虽不无道理，但已显陈旧过时。近十年来，left-pad的功能早已成为所有浏览器和运行时的标准配置。许多其他微型包同样已被淘汰，当前的主流趋势是避免发布或使用任何形式的微型包。
“零依赖”如今已成为前端领域的顶级营销术语。遗憾的是，消除依赖的过程仍在持续，彻底清除生态系统中的这类包已耗费过多时间。但这并非因为JavaScript社区从未关注过此问题。“扩充JS标准功能，弃用is-number”并非新颖见解或宝贵洞察。
更关键的是，大量非微型包同样受到波及。继续纠缠这个老生常谈或许有趣，却偏离了核心议题。
这项努力还受到少数不良行为者的阻挠。
典型案例：某位极具影响力的个人垄断项目所有权，并将自己的库作为依赖项强制纳入。后来发现他存在增加这些库下载量的经济利益：[https://github.com/A11yance/axobject-query/pull/354](https://github.com/A11yance/axobject-query/pull/354)
我所在的组织已有人提议开始使用大型语言模型从零构建完整的 NIH 技术栈。老板，我累了。
> 我所在的组织已有人提议开始使用大型语言模型从零构建完整的 NIH 技术栈。老板，我累了。
当DeepSeek开始检测代码是否被用于$enemy_of_state_org组织，进而生成暗藏后门或漏洞的代码时，一切就不再是儿戏了。
听起来很合理——它已经完成了一半。
事件发生后就看到这些抱怨。可没人给出具体方案，全是“改进包管理”这种空泛说辞。这算什么？我们早就有强制双因素认证和私有npm注册库了。
生态系统脆弱的根本原因在于大量包由单人开发者维护。只需一次入侵就能波及海量代码库。
我能想到的唯一预防方案是：当任何依赖项或子依赖项(其本身就是复杂的依赖树)更新时，对每个npm包进行自动化LLM扫描。
> _却无人提出具体方案._
文章中其实列举了大量具体建议：
“通过为可执行代码包引入通用签名、更小的信道和信任网络、可重复构建，以及负责任的包管理器采用的其他诸多简单明了的技术。”
不过我与作者同样悲观，认为这些建议不会被采纳。
哦，又是老生常谈。“照着发行版的做法做就行”。
好吧，那就来算算账。
Debian约有1000名志愿者维护2万个软件包，假设比例为20:1。
仅npm生态(不计其他平台)就拥有300万个软件包。
这意味着需要15万名志愿者——不计原始作者，光是无偿参与的个人就需15万。
这还只是一个仓库。
“胡说八道！”你反驳道，“其中真正有价值的包顶多十万个！”
好，那就“只需”五千名志愿者。Debian顶多只有千人规模，却可能是史上最常用软件的发源地。但没问题，我们肯定能找到五千名愿意免费工作的合格人才。
哦，但如何筛选这十万个包？好吧，用下载量？引用次数？网络中心度？好极了。但部分包将被驱逐出这个严谨打包的天堂。替代品呢？糟了，我们得让人手翻查三百万个包才能找出值得保留的。
我需要发行版推动者明白的是：大型C库的包管理器生态圈规模至少比其他领域小两个数量级，若将所有最大仓库合并计算，差距甚至接近三个数量级。语言生态系统的运作逻辑截然不同。对着云端咆哮“这本该轻而易举”根本无济于事。
开源社区中真正值得关注的库与框架大概只有5000个，其组织架构类似Eclipse基金会或Apache。其余要么是垃圾项目，要么是风险低的小型个人维护项目，要么就是企业雇员维护的专属资产。
_> 哦，又是老生常谈。“照着发行版的做法做就行”…但语言生态系统的运作逻辑根本不同。
规模失控的根源或许在于缺乏完善的包检测与维护机制——而那些令人厌烦的老生常谈恰恰提供了这些功能。
完善的包管理机制能实现双赢：包数量减少，质量提升。
能否一次性改造所有包？不能。只需为那些愿意迁移到新流程的作者或维护者打上质量标记。其余则标注警告——“该软件包未通过质量检测”。搞定！
为何鲜少有人探讨替代方案？[https://jsr.io/docs/trust](https://jsr.io/docs/trust)
我本想说自己在Deno上开发应用，这些应用独立于npm生态系统之外——但问题在于如今Deno已支持npm依赖，因此存在风险：供应链中若有成员使用npm，某个依赖就会突然再次暴露。
我坚持使用Deno标准库，因为它自成体系。
> 或许JavaScript标准与实现领域的领导者谷歌和Mozilla，将着手开发真正的JavaScript标准库，让left-pad这类微依赖成为历史。这可与整合工作相结合：将微型库合并为范围更统一、目的更整体的大型包，进而精简其依赖树。
这简直是我能想象到的最大程度的稻草人论证。这两种“不可能实现的解决方案”其实早已存在：
– ECMAScript标准已将`Strong.padStart()`定义为JavaScript“真正”标准库的一部分[1]
– 事实上已存在广为人知的lodash库[2]，正是将此类微工具整合为一体的典型
> 人们永远不会吸取教训。这种现象持续数十年，至今无人从中获得启示。这正是当代软件开发领域最典型的傲慢症结。
作者似乎纯粹出于憎恶心理而刻意贬低整个生态系统。
[1] [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe…](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart)
[2] [https://lodash.com/](https://lodash.com/)
没错，现在到了这样一个地步：那些声称left-pad未修复的人，反而更像是没在认真关注问题的表现。我基本不再纠正这类言论了，因为很明显存在相当一部分群体，他们就是喜欢对JS挑刺，不愿现实打破他们的幻想。
作者显然不是在说left-pad库至今仍是特定问题。他将其作为仍在发生的问题的_范例_提出。随后他指出：或许我们本应减少封装式JS代码的使用，更多软件解决方案本应(且理应始终)作为标准库或Lodash这类维护良好的包存在(尽管他未点名提及，仅阐述其体现的概念)。你似乎是只见树木不见森林了。
Pnpm新增设置以防范供应链攻击
[https://news.ycombinator.com/item?id=45286526](https://news.ycombinator.com/item?id=45286526)
yarn 功能更新：实现 npmMinimumReleaseAge 和 npmMinimumReleaseAgeExclude 配置选项
[https://github.com/yarnpkg/berry/pull/6901](https://github.com/yarnpkg/berry/pull/6901)
yarn 功能更新：实现 npmMinimumReleaseAge 和 npmMinimumReleaseAgeExclude 配置选项[https://github.com/yarnpkg/berry/pull/6901](https://github.com/yarnpkg/berry/pull/6901)
情况不太理想。若需紧急部署安全补丁，必须完全豁免该软件包的最低版本要求，无法仅允许特定版本。
根本上，解决方案并非技术层面的，而是社会/结构层面的。
企业要么对所用依赖项的签名负责，要么要求仓库对依赖项签名负责，要么继续维持现状。
第三种方案摊销成本最低。
> 没人会吸取教训。这种情况持续数十年，至今无人从中获得启示。这正是本世代[X]的典型傲慢。
[X]
“软件开发”
“气候变化”
“医疗改革”
“政治极化”…
> 作者似乎纯粹为了憎恨而憎恨[X]。
[X]
“生态系统”
“国家”
“政党”…
当包管理器配备能自动扫描更新的人工智能——它们识别恶意代码的能力远超人类——问题不就很快解决了？
不确定是否讽刺，但这主意糟透了。乐观情况是它会降低人类警惕性，让恶意代码攻击的成功率变成掷骰子。更可能的是，那些专门欺骗大型语言模型的混淆技术将为恶意代码打开闸门。