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