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

面试难道不是为了招合适自己业务的人吗？工作中我又不会让你手撸红黑树我面你这个干嘛？
有相关项目经验，有基本的行业了解，对应的编程语言用的够多，了解个大概对于应届生就可以了啊。
算法你只要能大概手撸个排序，能考虑清楚各种边界条件，逻辑思维能力基本就足够了。

群晖的系统里本身就带了个反向代理。给你另外两个跑 Docker 的配置反向代理就行了。
你需要配置一个统一的 DNS ，然后在里面把几个不同的域名指向你这三台机器。
再在这三个机器的反向代理里面，把不同域名过来的请求分发到不同端口上就行了。

或者更简单点，就配置一个反向代理，然后所有你这些域名全指过去，再从这个反向代理里面分发到另外三台机器的不同端口上。

既然不管别人说什么，只要不和你意你都不信，那何必来问？

当年就有人热衷于论坛上去扒各种 HIPS 规则，今天试一个明天试一个，还有各种评测。
最后搞得自己电脑三天两头重装。

这不就是一回事么。天道轮回，计算机这行里就没有新鲜事。

Rider 或者 VS2022 吧，2019 卡的不行。

@liaohongxing 不管你觉得有问题还是没问题，负责就好。

@liaohongxing “风险”就是指的你这种情况。因为搞明白能用不能用的成本非常高，有可能需要根据具体情况开庭吵一架才行，所以直接不用它就是最好的选择。