1
realpg 2020-04-27 22:02:52 +08:00
不懂你们 JS 程序员的引用方式
难道不精确限定版本么? |
2
Chingim 2020-04-27 22:06:28 +08:00 via Android
package-lock.json 是多么的重要
|
3
raymanr 2020-04-27 22:16:35 +08:00
引用这事情,感觉有点像把捅人的刀子交到了别人手上
|
4
nyanyh 2020-04-27 22:21:45 +08:00
left-pad 才过去几年,按理来说这点代码不应该自己实现吗,为什么要调用别人的库
|
6
matrix67 OP @raymanr 之前在 hn 上看到一个观点,说你同事的代码提交上来 review 了又 review,然后一个陌生人写的啥都不知道就合入然后升上去了。。。。。
|
7
firefox12 2020-04-27 22:34:12 +08:00
java 也一样, 几白兆的 jar maven 过来就开始跑了。
|
8
nyanyh 2020-04-27 22:35:58 +08:00
@matrix67 #5 省下两行代码,却在 package.json 里多了个依赖,该有的 import 一样不能缺,没看出到底节省了什么……
|
9
Kobayashi 2020-04-27 22:36:18 +08:00 via Android
我记得以前有个类似事件,也是非常短的库。我想不明白,这种一行的烂库有什么好引用的。
|
10
rayhy 2020-04-27 22:55:47 +08:00 via Android 1
可以的…看着蛮吓人。不过有个问题,这种几行代码的库,你们是怎么发现的?知道是为了避免重复造轮子,但这种感觉就是一个 gist 呀,Google 一下可能就找到了。反而发现这么一个库似乎不是那么容易…
|
11
james122333 2020-04-27 23:03:46 +08:00
这确实是个破烂库 测也只是测大概而已
测试是否 promise 用意何在... 看来又是大而全的阴谋 小而精不重要的东西 话说也不精 |
12
XanderChen 2020-04-27 23:06:22 +08:00
有句话怎么说的来着,
有时候免费的,反而更加昂贵。 |
13
wangyzj 2020-04-27 23:09:05 +08:00
CI 应该没测试
或者没 CI 应该都不是大项目 影响也都不会大 |
15
xiangyuecn 2020-04-27 23:17:17 +08:00
遇到这种事,只能一句 我屮艸芔茻 了。
我觉得根源还是 dependencies 的书写方式上,现在是 名称字符串:版本号字符串 这种形式,然后 npm 的 install 瞎几把下载,固定版本号没有传染性。 如果 dependencies 里面的版本号搞成对象形式,固定版本号必填,允许什么级别版本号升级兼容自己选择。那么根据最终使用如果使用的是固定版本号,安装的所有库都必须使用固定的版本号,版本的选择权就完全交给了库的使用者。传染性很重要。 说白了还是 npm 的设计有毛病。 |
16
james122333 2020-04-27 23:19:03 +08:00
面对过程强的地方在于只要知道过程中前后差异 只要能达成一样目的就替代掉了
弄个对象还要考虑对象相容 甚至弄个对象互转超级麻烦 |
17
love 2020-04-27 23:25:32 +08:00 1
@xiangyuecn 如果固定版本号,所有的库基本都无法共享同一份库了,比如 A 库用了 c 库 1.01 版本,B 库用了 c 库 1.02 版,内存和硬盘中就有二份基本差不多的重复代码了,磁盘和内存用量要爆炸一波,用处却没多少。现在的 package-lock 才是最佳选择。
|
18
james122333 2020-04-27 23:26:23 +08:00
只要不是写烂过程或者语言本身函式用法烂 函式好的多
|
20
blless 2020-04-27 23:38:37 +08:00 via Android
golang 程序员点了个赞
|
21
xiangyuecn 2020-04-27 23:38:38 +08:00
@love #17 我觉得这个问题,不应该叫做问题。目测所有引用别的库的工具,都会产生此问题(他们怎么解决的我就不管了,也不懂):
1. A 引用了 Z 的大版本 1.x,B 引用了 Z 的大版本 1.X,你引用了 AB,似乎没有问题 2. A 引用了 Z 的大版本 1.X,B 引用了 Z 的小版本 1.1,你引用了 AB,当前 Z 版本 1.2,似乎是就有问题了,是让 A 乖乖就范呢还是怎么个倒退方法 3. A 引用了 Z 的大版本 1.x,B 引用了 Z 的大版本 2.X,你引用了 AB,矛盾凸显 |
22
DOLLOR 2020-04-27 23:43:55 +08:00
上次崩的好像是 isArray,同这次的 is-promise,都是数据类型判断相关的代码。
|
23
niubee1 2020-04-27 23:53:16 +08:00
一行代码的事情要搞成几行代码,真是走火入魔啊
|
24
love 2020-04-27 23:56:30 +08:00
@xiangyuecn npm 目前是会最大可能调合合并成引用同一份代码,实在不行才会分成二份(比如引用不兼容版本)。
至于别的语言没这问题那是因为它们的库都是大粒度的,这种几十几百行代码的各个库都自己写了一份,一个项目没多少第三方库数量,不象 npm 随便一个项目就有万千上万个,这样子开发当然是很爽了,基本你要的啥工具都有。 |
25
xiangyuecn 2020-04-28 00:17:29 +08:00
@love 嗯,原来是这样😃
|
26
Austaras 2020-04-28 05:26:25 +08:00
这个的核心问题在于 npm 默认是会改 lock 的
所以大家都来用 yarn 吧 |
27
zhw2590582 2020-04-28 08:34:44 +08:00
我想起有个 npm 包是用来判断一个数字是否偶数,几百万的下载量,然后就出现另一个包,直接引用前面那个包,判断非偶数(奇数),又几百万下载量。
|
28
firefox12 2020-04-28 08:43:13 +08:00 via iPhone
@baozijun 有什么区别吗? 那些被引用的代码 你也从来没读过 没 review 过。当 spring 升级后 这些引用升级了 你会去 review 吗? 所以和 npm 有什么区别?
|
29
ericgui 2020-04-28 08:45:07 +08:00
npm 里面太多 one-liner 了
|
30
msg7086 2020-04-28 08:58:18 +08:00
这不是 yarn 早就解决了么?为什么要用一个不能锁版本的软件包管理?
|
31
annielong 2020-04-28 09:18:50 +08:00
百行内的库绝不引用,太傻了
|
32
SilentDepth 2020-04-28 09:31:49 +08:00 3
@nyanyh #8 别人可能花了很大精力找出的最优实现、完善的单元测试和覆盖度测试,给你带来的不应当只是「省下两行代码」
|
34
shunia 2020-04-28 11:25:50 +08:00
yarn,pnpm 解君愁
npm 也一直在进步,但是似乎没有解决这个 nodejs 设计里留下来的问题。 |
35
yanguangs 2020-04-28 11:35:08 +08:00
@firefox12
java 的基本库很丰富,不会有这种 is-number is-promise is-xxx 的几十行的库. 但是 js 的 is-number 这种库偏偏就有些必要, 因为 js 的隐式转换以及 truthy falsy 想覆盖全真的很累. |
36
yanguangs 2020-04-28 11:37:33 +08:00
|
37
iugo 2020-04-28 12:34:59 +08:00
我支持这种依赖的生态. 但值得优化的地方是, 更好的标准库.
比如 `String.prototype.padStart()` 这种改进. |
38
firefox12 2020-04-28 13:07:33 +08:00
@yanguangs 你根本没搞清楚 核心是 review 而不是 1 行 2 行。 你一闭眼 进来了 100M Java 库,java 库开源的品质挺好,所以没问题, 而 js 呢? 你放进来的一下子就有问题了。 本质都一样, 你都是信任发布方,自己没有真正 review 过。
真的让我 review 这 100M java 库 我也没能力。java 库 要 review jvm 要不要 review. cpu 硬件呢? 社会效率变得无比底下。所以 这问题很难解。只不过 js 这种 实在就是太烂了。 |
39
charlie21 2020-04-28 18:25:44 +08:00
你们 JS 圈又出这事,上一次叫啥来着 left-pad ?
|
40
enrio 2020-04-28 20:32:54 +08:00
@zhw2590582 这很前端,把复用做到了极致🤡。
|
41
jones2000 2020-05-07 01:24:13 +08:00
这个没办法,出来混总要还的。
没有技术积累, 都用开源拼拼凑凑的,这个跟裸奔没什么区别。 |