Open YIXUNFE opened 8 years ago
作为一个前端er，相信你不会不认识 NPM，而就是这个广为人知的 NPM，最近悲剧了！
有个叫做 Azer 的开源贡献者，因为不满 NPM 官方对于他个人项目的干扰，删除了他在 NPM 上发布的所有开源项目。而其中的一个仅 11 行代码的 left-pad 模块的消失，直接造成了包括 Babel、React Native 等重量级开源项目无法安装。这一事件直接引爆了 NPM 圈。
left-pad
我们先来看看一下子广为人知的 left-pad 模块的代码：
这个模块仅仅只输出一个函数，即图中的 leftpad 方法，作用也仅仅是做字符串处理。而就是这么一个轻巧简易的函数，竟然被众多大牌开源项目依赖，我们不禁疑惑：“写一个 util 不行吗？”
leftpad
我在这里也给不出这个问题的答案，但是可以和大家聊聊我对模块引用的理解。
选择引用开源模块时先权衡自己对于该功能的开发成本和维护成本，在允许的情况下尽量自己实现依赖模块的功能。一般只在实现成本或维护成本较高时才考虑引用开源模块。
先说说自己实现功能较引用模块的优势：
关于引用模块的安全隐患会在后面讲到。
这里也提一下引用开源模块的优势：
也有和我的观点不同的，
模块和代码行数没有必然联系，只和抽象有关系。
这种观点将模块着眼于抽象上，只要模块能抽象的足够好，就成。但是如何定义抽象的足够好，个人觉得这是个主观命题，人人都有自己的理解。
在这次事件爆发之前就已经有很多人提出 NPM 模块的安全隐患了。当一个恶意模块以一个与知名模块类似的名字发布时，可能就会有用户会安装到该恶意模块，在执行时被恶意程序侵害。
比如大家都知道有个叫 gulp 的工具可以做脚手架，那么就用它来举个例子。
gulp
我先发布一个无害的模块，在它的 package.json 文件中写上依赖：
package.json
//package.json dependencies: { "gu1p": "1.0.0" }
然后在主文件中引用该模块：
//app.js var gulp = require('gu1p')()
第一眼看上去是依赖和调用了 gulp，但其实是安装并被调用的是 gu1p 模块，查了一个字哦！傻眼了吧？你在运行这个模块时，恶意程序就会胡作非为了。
gu1p
如何防范这种情况的发生目前还没有很好的主动防御措施，全靠程序猿自觉。希望这潭水不会被越搅越浑。
导致这次事件发生的根本原因其实就在于 NPM Package Name 的问题上。
Azer 自己创建的 Kik 模块发布后，Kik.com 公司的人希望他们能够使用 Kik 这个名字发布他们自己的内容，但是遭到 Azer 拒绝。最后 NPM 强行将 Kik 模块所有权转移给了 Kik.com。
Kik
详细可以从 整理的邮件列表中翻看事件始末。
NPM 在处理包名争端的过程中扮演最终裁决的角色。
NPM 官方文档中简明的阐述了在产生域名争端情况下的一般解决流程。
Get the author email with npm owner ls Email the author, CC support@npmjs.com After a few weeks, if there's no resolution, we'll sort it out. Don't squat on package names. Publish code or move out of the way.
Don't squat on package names. Publish code or move out of the way.
可以看出，在双方无法达成有效解决方案时，NPM 公司会解决这件事。
NPM Package Name 的争夺战好像以前没怎么听闻过，但是域名争夺战比较多。比如最近的 weixin.com 域名争夺战。由于 weixin.com 的名下产品（网站）从事与腾讯的微信相关业务，为了不误导用户，法院判决 weixin.com 所有权归腾讯所有。这里我们得到一条信息：
如果域名抢注成功并且该域名下的网站没有做相关公司产品所涉业务的，是难以通过法律途径要求抢注者归还域名所有权的，因为域名注册就是将就先到先得的。
从这点来看，Kik 这个模块如果真的涉及到了 Kik.com 公司的产品业务的，NPM 官方将其归还 Kik.com 也并非不可。
https://www.zhihu.com/question/41694868 http://zhuanlan.zhihu.com/ibuick/20671763
weixin.com 域名仲裁案件
NPM 悲剧了！
作为一个前端er，相信你不会不认识 NPM，而就是这个广为人知的 NPM，最近悲剧了！
有个叫做 Azer 的开源贡献者，因为不满 NPM 官方对于他个人项目的干扰，删除了他在 NPM 上发布的所有开源项目。而其中的一个仅 11 行代码的
left-pad模块的消失，直接造成了包括 Babel、React Native 等重量级开源项目无法安装。这一事件直接引爆了 NPM 圈。关于 left-pad 事件的讨论
我们先来看看一下子广为人知的
left-pad模块的代码：这个模块仅仅只输出一个函数，即图中的
leftpad方法，作用也仅仅是做字符串处理。而就是这么一个轻巧简易的函数，竟然被众多大牌开源项目依赖，我们不禁疑惑：“写一个 util 不行吗？”我在这里也给不出这个问题的答案，但是可以和大家聊聊我对模块引用的理解。
先说说自己实现功能较引用模块的优势：
关于引用模块的安全隐患会在后面讲到。
这里也提一下引用开源模块的优势：
功能升级这一条真的是勉强写进去的，因为 N 多的开源模块，升个级立马 API 大变样:joy:
模块与抽象
也有和我的观点不同的，
这种观点将模块着眼于抽象上，只要模块能抽象的足够好，就成。但是如何定义抽象的足够好，个人觉得这是个主观命题，人人都有自己的理解。
关于开源模块的安全隐患
在这次事件爆发之前就已经有很多人提出 NPM 模块的安全隐患了。当一个恶意模块以一个与知名模块类似的名字发布时，可能就会有用户会安装到该恶意模块，在执行时被恶意程序侵害。
比如大家都知道有个叫
gulp的工具可以做脚手架，那么就用它来举个例子。我先发布一个无害的模块，在它的
package.json文件中写上依赖：然后在主文件中引用该模块：
第一眼看上去是依赖和调用了
gulp，但其实是安装并被调用的是gu1p模块，查了一个字哦！傻眼了吧？你在运行这个模块时，恶意程序就会胡作非为了。如何防范这种情况的发生目前还没有很好的主动防御措施，全靠程序猿自觉。希望这潭水不会被越搅越浑。
关于 NPM Package Name
导致这次事件发生的根本原因其实就在于 NPM Package Name 的问题上。
Azer 自己创建的 Kik 模块发布后，Kik.com 公司的人希望他们能够使用
Kik这个名字发布他们自己的内容，但是遭到 Azer 拒绝。最后 NPM 强行将 Kik 模块所有权转移给了 Kik.com。详细可以从 整理的邮件列表中翻看事件始末。
包名争端的处理
NPM 在处理包名争端的过程中扮演最终裁决的角色。
NPM 官方文档中简明的阐述了在产生域名争端情况下的一般解决流程。
可以看出，在双方无法达成有效解决方案时，NPM 公司会解决这件事。
NPM Package Name 的争夺战好像以前没怎么听闻过，但是域名争夺战比较多。比如最近的 weixin.com 域名争夺战。由于 weixin.com 的名下产品（网站）从事与腾讯的微信相关业务，为了不误导用户，法院判决 weixin.com 所有权归腾讯所有。这里我们得到一条信息：
从这点来看，Kik 这个模块如果真的涉及到了 Kik.com 公司的产品业务的，NPM 官方将其归还 Kik.com 也并非不可。
文中的一些八卦参考：
https://www.zhihu.com/question/41694868 http://zhuanlan.zhihu.com/ibuick/20671763
weixin.com 域名仲裁案件
Thanks