降温应该没那么快吧。
而且据说火山口已经埋到水下了，应该不会像第一次那样直接喷上天。

撸铁
蹲个 PR 就冷静了，没静下来就再蹲一个。
或者跑个 10 公里，保证脑子里啥浮躁想法都没有了。

你这就是个 string ，format 个啥。。。

@DuDuDu0o0 和 JB 家的 IDE 集成的更好一些。
但实际上最关键的还是要减少每次 Review 的代码量，尽可能细的拆分功能。
不然一次搞上去十几个类，几百行代码，折腾啥工具都没用。
代码足够少你用 Gitlab 的 Review 都够了

你那个 PS 的命令和 Win32 函数获取的是安装好的打印机。
这窗口右下角那个功能是从 Windows Update 里获取可以支持的打印机驱动列表。
现在已经显示的东西是你以前安装过的打印机驱动，存在了 Windows 的驱动缓存里。
你可以直接看看 C:\Windows\INF 有没有你想要的东西，里面一堆的 INF ，搜 HP 的。

@easychen 你说得对，加油。

@easychen 搜一下，哪怕搜一下呢，Google 这俩第一条就是。
SSPL 是 MongoDB 为了应对云服务厂商白嫖做出来的协议。
GTLB 是 Gitlab 上市公司代码
所以你这是既没认真调查过如何使用协议对商业化做限制，也没认真调查过相似公司案例吗。。。
唉，亏我还认真回你，算了。

如果只是想做个软件那也就算了，如果打算做成产品，你首先要考虑的是你作为商品的价值和盈利模式是否能持续。
最简单的，我直接用你开源软件搭云服务，你如何告倒我？上 SSPL ？
面向企业的话还好说，面向个人的服务就更难了，但哪怕是面向企业这种模式的盈利能力也不是很强，成本也极高。
你可以看看 GTLB ，这都是做的好的了。

@secondwtq
我不是特指 colors ，faker 或者 left pad 。更没有说 colors 或者 faker 这种东西应该是语言自带的一部分。提到 isArray 是因为现在 ES 标准已经有了，left pad 是因为 npm 之前就因为它的问题闹过一次，你可以搜一下这个库的历史。

我的意思是，现在对于规模差不多的项目来说，NPM 拥有远比其他语言类似规模项目更多，更复杂，来源更为多样的依赖树。而造成现在这个局面，并不只是单单某个库，或者某几个库，或者前面楼提到的委员会等等单一因素导致的。

从最开始 JS 设计的不完善，导致大家都必须为各种功能造轮子。后来发现分享自己的轮子可以带来社区热度，使用别人的轮子也更方便，逐渐变得一个简单的功能也依赖众多的轮子，也热衷于造轮子。这样社区热度上去了，但也埋下了隐患。虽然委员会也做了一定程度对语言的补救，但社区的惯性不是那么容易改的。直到现在 isArray 这种早就内置的功能，NPM 上还有 400 万的下载。

当项目的复杂度远超团队能控制的规模时，失控是不可避免的。依赖树也是这样，Colors 和 Faker 只是两个例子。init 一个项目随便引个大型框架，node_modules 里就大几百上千个直接间接依赖了。只有几十个依赖的话，每次更新还能去看看 release note 。上千个库怎么看。谁知道哪个不维护了，哪个下了毒。

不过这也扯远了。只是我觉得，以后可能某些大型框架会逐渐砍掉大部分第三方依赖，也可能有个更好的包管理替代 NPM 。但是如果 NPM 整个生态不做改进的话，以后类似的事情不可避免。

@abcbuzhiming 确实，只能说委员会各有利益所在，做个这东西并不涉及到他们的核心利益。

@abcbuzhiming NPM 的主要问题不在 NPM ，在于 JS 。
JS 没有完善的 Commons 这种库，语言核心的 BCL 各种残疾。所以即使是相对简单的功能，都要用一些小型的，个人维护的库来组合起来完成。
没有正常的 String 操作库，之前炸了 React 的 leftpad 都得找个人维护的库来做。
甚至 IsArray 这种你明显感觉应该是 Collection 一部分的东西，都得是个第三方库。
所以搞得你引几个大型库，都能在 node_modules 里面搞出来几百上千个依赖。
就算是单个库出问题的概率一样，你一个项目引上千个依赖，出问题的概率肯定比你只有几十上百个依赖的项目出问题的概率大。
更别说 NPM 公司确实是不在乎了，left pad 就是前车之鉴。

@stkstkss 麻烦的在于间接引用，你也不知道你哪个依赖库就引了它进来。。。。
最好搜一下 node_modules 看看

@sudoy 所以说 @kop1989 说的并没有错
- 删库跑路本质上是破坏开源社区的行为
- 商业公司使用开源库且不付费是不道德的，但并不违反开源协议
- 商业公司剽窃 faker cloud 是恶劣的违法行为
几件事是互相独立的，非要混在一起说不是自己根本分不清就是故意在搅混水。

对于第一点多说几句，其实你的作品一旦公开，接受了开源社区的 Issue 或者 PR ，它本质上已经属于开源社区的一部分了。只是你作为初始 Owner ，大家都默认你对这个作品有绝对控制权。
但这个实际上是有问题的，比如你接受了一个对你作品完全重构的 PR ，大部分贡献都不是你自己了，那这个 Owner 怎么算？所以一般大一些的库，都会要求提交 Commit 以前签署 CLA ，以明确作品的权利归属。特别是当你用了 Apache 一类涉及到专利的 License 更是会有问题。

当你作为 Owner ，对作品做出破坏性操作的时候，实际上是损害了其他贡献者与你的信任关系。比如极端点你在库里面放挖矿代码，或者放个圣诞大礼包。但签了 CLA 也好，没签默认的也好，也仅仅只是让人从道德上谴责两句，这种行为和商业公司使用作品不付费没什么区别。

所以说大部分开源项目就只是“项目”，而非“产品”。一个“产品”面向的对象应该是有预算，且有权做购买决策的人群。而开源项目面向的对象大部分都是码农，他们都是拿固定工资的。这也是为什么大部分开源项目都没办法有稳定收入，全靠捐赠。

@sudoy 确实，所以每次只要我一上头在网上跟别人辩论就罚自己做一个小时有氧。
有效控制住了自己教育别人的欲望。