2024 年初，一位名叫 PatrickJS 的 npm 用户发布了一个名为 “everything”的包，这个包依赖于所有公开的 npm 包，从而创建了数百万个传递依赖。这个包及其3000多个子包导致了任何安装它的用户遭受拒绝服务（DOS）攻击，表现为存储空间耗尽和系统资源枯竭。

这并不是 npm 上第一次出现类似的恶作剧。去年，“no-one-left-behind”包也尝试过类似的事情，并在被移除后以超过33,000个子包的不同形式重新出现。此外，2012年，一个名为“hoarders”的包曾直接依赖于 npm 上的每个模块（约20,000个），最终因给注册表数据库带来的压力而被 npm 包管理器的创建者 Isaac Schlueter 取消。

“everything”包及其子包和依赖不仅是一个数字恶作剧，它还凸显了 npm 生态系统中的包管理持续挑战。这提醒开发者注意依赖的连锁效应，以及在包的创建、维护和使用过程中的谨慎性。

#NPM #前端

https://socket.dev/blog/when-everything-becomes-too-much

实时发布在 npm 上检测到的恶意软件包。

📣 We tweet malicious packages detected on npm in real-time. 🚨 Not affiliated with @npmjs or @github. 🛡 Powered by the @SocketSecurity threat feed. ✨

#Tools #x #NPM

https://twitter.com/npm_malware

Node.js 技术指导委员会（TSC）明确表示：不打算从官方版本中移除 npm。

Node.js 技术指导委员会 (TSC) 近期就是否默认启用 Corepack 这一话题进行了讨论，并确认了一个重要的共识：没有计划从 Node.js 发行版中移除 npm。这个讨论为 Corepack 的集成和 npm 的未来提供了明确的方向。

通过 Geoffrey Booth TSC 成员的 PR 合并，达成了共识记录，其中明确指出，移除 npm 并非项目目标。另一方面，这也加强了与 npm 客户端的“特殊关系”，确认 npm 是因历史原因以及其作为 npm 注册表的参考实现而被包含在 Node.js 发行版中。

Node.js 更新的技术优先事项文件中新增了 Package Management 一节，强调了 Node.js 将 npm 作为其发行版一部分提供包管理器的原因，这既因 npm 是 JavaScript 软件的主要来源，也因其历史地位——自 2011 年 npm 被纳入时就成为唯一的 JavaScript 包管理器。

此外，对于“Node.js 是否应该自带一个包管理器”的问题，TSC 成员 Myles Borins 建议抛开修辞，从实际角度出发，努力就建筑决策达成共识。Borins 也指出，简单地移除 npm 会在没有明确替代方案的情况下降低 Node.js 的用户体验，强调了目标应是建设性的，而不应是排他性的。

TSC 同时还计划在下周的会议上继续讨论有关“占位符”可执行文件的政策，这与 Node.js 是否将安装用于引用不包括在 Node.js 的二进制文件、脚本等的链接有关。主要考虑的问题是占位符是否会使 Node.js 负有任何由占位符中的安全问题造成的责任。Booth 的 PR 建议，Node.js 不应创建占位符可执行文件（这类命令指代未与 Node.js 一同发行的软件，而是在运行命令时下载软件）。

此次会议预定下一步讨论的内容，以决定 Corepack 相关决策，此决定将有助于处理开放的 PR，其中包括默认启用 yarn 和 pnpm Corepack 二进制文件以及一个关于替代默认启用 Corepack 的提案。这场关于 Corepack 的讨论仍在进行中。

#NodeJs #NPM

https://socket.dev/blog/node-js-tsc-confirms-no-intention-to-remove-npm-from-distribution

如何从 0 到 1 创建一个 NPM 包，这篇教程已经算是很详细了，可以了解里面用了什么库来进行辅助开发。

@arethetypeswrong/cli 库之前没在 npm 包中使用过，可以用于检查包导出是否正确，比如 package.json 中没设置 main 的路径。

#教程 #npm

https://www.totaltypescript.com/how-to-create-an-npm-package

np 是一个高效的 npm 发布工具，它通过交互式界面简化了发布流程，自动处理版本控制、依赖检查、测试运行等任务，并支持现代包管理器，极大提升了前端和后端开发者在 JavaScript 生态系统中发布包的效率和安全性。

#Tools #NPM

https://github.com/sindresorhus/np

npm 应该从新软件包中删除默认许可证（ISC）

extremq 认为 npm 在初始化新包时默认设置为 ISC 许可证是不合理的，甚至可能是危险的。npm 是 JavaScript 编程语言的包管理器，由 npm, Inc. 维护，是 Node.js 的默认包管理器。软件工程师需要了解不同类型的许可证以及如何使用它们，因为许可证决定了开发者在项目中使用这些包时的权利和义务，例如是否可以商业化使用、是否需要提供源代码、是否需要提供归属权等。

当开发者使用 npm init 命令初始化一个新包时，npm 默认将许可证设置为 ISC，但并不会告知开发者关于 ISC 许可证的具体信息，甚至没有提供如何不使用许可证的选项。这可能导致开发者在不知情的情况下发布了带有 ISC 许可证的包，而他们可能并不了解该许可证的含义。例如，开发者可能会在意识到自己并未真正选择许可证后，将其更改为与 ISC 不兼容的许可证，如 GPL，这可能会引发法律纠纷。因为法院可能会将此解释为开发者最初意图使用 GPL，从而使得所有使用了 ISC 许可证的用户面临被起诉的风险；或者法院可能会认为开发者最初发布的版本永远受 ISC 许可证的约束，而用户可以不受 GPL 限制地使用该版本。

此外，还有开发者表示自己本不想为项目添加许可证，却因为 npm 默认设置为 ISC，导致项目被他人修改并添加了 ISC 许可证，这使得开发者原本未受保护的代码（如通过代码生成的像素艺术精灵）被错误地授权为开源。这种默认设置不仅给开发者带来了困扰，还可能引发版权问题。

extremq 指出，其他包管理器如 Rust 的 cargo 和 Python 的 PyPi 并不会在创建包时默认添加许可证，而是让用户自行选择。在 GitHub 上选择许可证时，也没有默认选项，而是提供了一份常见许可证的列表，并附有免责声明和许可证的完整内容。此外，extremq 还提到，未明确指定许可证的代码与使用了 “Unlicense” 许可证的代码是不同的。未指定许可证的代码属于版权所有者，未经版权所有者明确许可，其他人不能修改或分发；而 “Unlicense” 许可证则是将代码置于公有领域。extremq 认为，npm 默认设置为 ISC 许可证的做法是不合理的，甚至可能在法律上无效。

#npm

https://extremq.com/npm-should-remove-the-default-license-from-new-packages-isc/