这是一个创建于 1052 天前的主题，其中的信息可能已经有所发展或是发生改变。
作者在 NPM 包里放了死循环。如果你的项目有直接或者间接引用的话，很可能会挂掉。 https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
项目的依赖管理还是要谨慎一些，特别是当不指定具体版本号的时候，一旦更新很可能会炸掉。
NPM 这种动不动几百上千个依赖的，真要认真管起来的话简直是噩梦。
 |
101
ebushicao 2022-01-10 19:24:37 +08:00
唉，前端的坑太多了，浏览器版本兼容，代码编译和文件打包，包依赖管理，各种和编码无关的问题需要处理。
|
 |
102
fanxasy 2022-01-10 19:41:03 +08:00
npm 的优势瞬间反转了。。叹息一声
|
 |
104
abcbuzhiming 2022-01-10 19:55:57 +08:00  5
@LawlietZ Java 领域的主流包管理工具就是 maven ，背后的中央仓库，你去网上找几个“被黑客黑进去加了恶意代码”，“或者某个作者发疯在升级包里下毒”，然后造成后果的事件让我开开眼。我反正是放狗找过，没找到过类似的事件。maven 背后的审核机制拦住了这些东西。
顺便说一句，python 那边包管理工具我也没听说过这样的事情。我还专门去搜过，也没找到，如果有麻烦让我开开眼。 这就是我刚才说的，和别人家的包管理工具比起来，NPM 跟没人管一样，这很不正常，黑客，作者发疯都是很正常的事情。第一次听说 NPM 被人黑进去改了代码然后造成了严重后果时，我是震惊的，但是后来又来了几次我就变成了莫名其妙——还是那句话，npm 没人管的吗？谁在负责 npm 的包审核工作？堂堂 js 基金会对不管事的吗？ |
 |
105
ddzy 2022-01-10 20:22:55 +08:00
我们的前端项目崩了一天，无限乱码，艹找了一天的原因
|
 |
106
Mithril OP 3
@abcbuzhiming NPM 的主要问题不在 NPM ，在于 JS 。
JS 没有完善的 Commons 这种库，语言核心的 BCL 各种残疾。所以即使是相对简单的功能，都要用一些小型的，个人维护的库来组合起来完成。 没有正常的 String 操作库，之前炸了 React 的 leftpad 都得找个人维护的库来做。 甚至 IsArray 这种你明显感觉应该是 Collection 一部分的东西，都得是个第三方库。 所以搞得你引几个大型库，都能在 node_modules 里面搞出来几百上千个依赖。 就算是单个库出问题的概率一样，你一个项目引上千个依赖，出问题的概率肯定比你只有几十上百个依赖的项目出问题的概率大。 更别说 NPM 公司确实是不在乎了，left pad 就是前车之鉴。 |
 |
107
shutongxinq 2022-01-10 21:15:43 +08:00 via iPhone 1
@dianso 自古多少豪杰都是散尽家财来养望，他一个 nobody 白嫖了 reputation ，该知足了吧，他闭源的话 reputation 能白嫖吗？自己不知道怎么用 reputation ，作者不应该反思一下？
|
 |
108
bigxianyu 2022-01-10 21:36:40 +08:00 via Android
@abcbuzhiming 一般公司内部会自己管理一个镜像 maven 仓库的
|
 |
109
rioshikelong121 2022-01-10 21:54:59 +08:00
这和前端乱不乱有个毛的关系。无脑刷梗还用不对地方真的烦人。
|
|
110
abcbuzhiming 2022-01-10 21:58:14 +08:00 4
@Mithril 我认为这不是语言的罪过，现在谁负责 js 的语言进化的方向，谁就该背这个锅，没有 commons 库？开发一个呗，java 又不是从天下掉下来的时候就什么都有的的，jcp 委员会付出了多少努力？ JavaScript 标准委员会这么多年，除了不停的加语法糖，为啥不干这个标准库的工作？还有 js 基金会，npm 公司不在乎不管，那这个基金会也不在乎？也不管？那这个锅它们不背，谁背？
|
|
112
Mithril OP @abcbuzhiming 确实，只能说委员会各有利益所在，做个这东西并不涉及到他们的核心利益。
|
 |
113
DiamondYuan 2022-01-10 22:50:12 +08:00
|
 |
115
secondwtq 2022-01-11 00:22:58 +08:00
@Mithril #106
JS 很多设计我也不喜欢，但是 Colors 和 Faker 这俩玩意怎么想都不像是语言标准库应该自带的啊 ... 标准库设计得再好也避免不了今天这个问题。 （甚至包括 left-pad 我都不认为是标准库必须应该包含的，并不是所有语言都有这个标准库函数，有的语言会用 format string 替代这个东西，理论上满足大部分场景，但是这样只能用一个字符来 pad ，left-pad 和新的 padStart 是支持用字符串的（ Python 最奇葩既可以 format 又可以用 ljust/rjust ，但是又只支持一个字符）。 这么推广下去，标准库必然会陷入一种总有人说”我觉得这个功能很常用啊，为什么你没有？你不‘正常’”的怪圈中。增强标准库和提供类标准库功能的库很多语言都有，比如 Python 的 dateutil ，Rust 的 serde ，Go 的 cli ，Swift 的 SwifterSwift ，C++ 和 Java 更是有 Boost 和 Guava 这种庞然大物。能碎到让人围观看戏的可只有 JS 一个） |
 |
116
az467 2022-01-11 00:35:43 +08:00
我就想知道老哥为啥要自制炸弹😆😆😆
|
|
117
Mithril OP 1
@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 整个生态不做改进的话，以后类似的事情不可避免。 |
 |
118
Greatshu 2022-01-11 01:08:42 +08:00 via Android 1
支持作者，没加挖矿和广告联盟已经是最大的克制了
|
 |
119
binux 2022-01-11 05:37:56 +08:00 via Android 2
在 UI 上加圣诞特效 X
在代码中加死循环 V |
 |
120
xuanbg 2022-01-11 08:16:01 +08:00
@LawlietZ maven 的话，可以轻松换一个无毒版本，并且排除有毒版本。这样即使别的依赖使用了有毒版本，也能不受任何影响。
|
 |
121
zxcslove 2022-01-11 08:45:21 +08:00
妥妥的加速主义
|
 |
122
yuezk 2022-01-11 09:23:36 +08:00
用 yarn 吧，默认锁版本，靠语义化版本号自动更新还是有点不太靠谱
|
 |
123
yzxhzxsw 2022-01-11 09:38:40 +08:00
一袋米要扛几楼
|
 |
124
karloku 2022-01-11 10:33:30 +08:00
@Cielsky 锁包了就没事. npm i 时生成 package-lock 都是默认选项了, 用 npm ci 能保证按照 package-lock.json 里的依赖进行安装.
而且 npm i 也只会在发现写在 package.json 里的项目有新版本时更新 package-lock.json. 非库项目不要用 ^ 指定依赖版本, 应该直接指定确定的版本号. 这样只有手动升级的时候才会导致 lock 变更, 可以进行测试. |
 |
125
skiy 2022-01-11 21:35:04 +08:00
|
Select Language