1
xabc 2019-05-28 20:48:19 +08:00 via iPhone
node.js 就是因为这个垃圾包死掉的
没人负责,没人统筹,一包垃圾,不死才怪 |
2
HuasLeung 2019-05-28 20:51:52 +08:00 via Android
Node.js 创始人 Ryan Dahl 都嫌弃 Node 的槽点,搞新的开源项目 Deno 去了
|
3
mocyx 2019-05-28 20:57:59 +08:00
为什么我觉得还挺好?
绝对不会出现诡异问题,所有依赖都自己掌控 |
4
lihongjie0209 2019-05-28 21:00:04 +08:00
@mocyx 你用 maven 能出现什么诡异的问题?
|
5
ibegyourpardon 2019-05-28 21:06:32 +08:00
你还别说,我记得上次哪听说 Python 都要学着这么干了。
理由无非是全局的包和各个项目下的依赖不一样,大家现在都用 pyenv,venv,pipenv 之类的在不同项目中加载不同的,所以好像是 pip 还是啥的要搞一套类似 Node 这样的玩法,没指定走全局,当前目录下有的话走当前目录…还能方便打包 blahblah,毕竟你看 electron 那带的东西。 道理是对的,但我总觉得哪里还是有点不对劲。好像可以有更省事的方法来着。 |
6
karnaugh 2019-05-28 21:08:54 +08:00
你这个项目用的 vue 是 1.x 的那个项目的是 2.x 的,如果只存一份,会怎样?
两份都存的话,后续的 yarn 之类的就这么操作的 |
7
crysislinux 2019-05-28 21:10:05 +08:00
我就喜欢现在这样
|
8
andylsr 2019-05-28 21:10:32 +08:00 via Android
@ibegyourpardon 也没那么绝对~~py 的 env 也不是完全独立~有些用到系统依赖的就 gg 了
|
9
mritd 2019-05-28 21:10:45 +08:00 via iPhone 2
三行 js,npm install 一下比 jdk 都大
|
10
mritd 2019-05-28 21:13:14 +08:00 via iPhone 3
其实,最骚的是有些包自己去 Github 下东西,更骚的是这东西还可能已经被删了,你想想一下你用 mvn install 一下下载一个 jar,然后这个 jar 还可能去 github 下载一个 exe,最后你发现 release 页 exe 被作者删除了
|
11
abcbuzhiming OP @karnaugh 这个难道不能在全局路径下 vue1.x 和 2.x 共存吗?这没什么吧,大部分包管理工具都是这么干的,多版本共存,每个版本只留一份
|
12
lizheming 2019-05-28 21:24:09 +08:00
cnpm 就修改了逻辑,所有的模块都是全局一个版本,项目下面的都只是全局的软链。
|
13
ibegyourpardon 2019-05-28 21:25:41 +08:00
|
14
mritd 2019-05-28 21:27:53 +08:00 via iPhone
@ibegyourpardon #13 而且这货不走你设置的那些缓存的,调 CI 跟吃了一坨屎一样难受
|
15
WittBulter 2019-05-28 22:44:57 +08:00
@mritd 存在外部非 npm 依赖的包可以不要用,npm 一开始的设计允许外部依赖还是一个挺 open 的,不然现在 github package 也没办法用这个 cli。这是给你用公司私有源或者紧急情况下自己 release fork 的包等等解决方案。
这么多人吐槽不用全局包,但 node 社区完全是有的啊,用 yarn2 不就完事了,什么 "node.js 就是因为这个死的" 都出来了,真的有了解过这个社区吗。 而且说到局部包和版本控制这个问题也和社区本身有关,因为社区的包太多了而且非常活跃,版本爆炸依赖复杂,所以这也是一个当时看起来比较好的解决方式,虽然以如今的眼光看有一些弊端,如分析依赖对比可用版本更新需要花费很多时间、磁盘读写时间长、没有过期危险的依赖警告 (有所改善了),但社区也一直在推陈出新,包括楼上说的缓存,yarn 就做的不错,还有很多 CI 也开始了专业级别的 nodejs 缓存等等,以我的视角看,在众多语言社区的包管理上,虽然算不上好,但绝不至于让语言死掉。 |
16
shuichengjian 2019-05-28 22:47:09 +08:00
我觉得没什么问题,就是有些 node modules 莫名失踪,才愁人。。。
|
17
KuroNekoFan 2019-05-28 23:14:13 +08:00 via iPhone 2
npm5 体验很好了吧,顺便为什么这贴压根没提 java 都能引来 ptsd 患者……
|
18
Osk 2019-05-29 01:29:18 +08:00 via Android
我一直很郁闷的是 node_modules 动不动就以万计的文件,真的是硬件配置限制了我的想像
|
19
OSF2E 2019-05-29 01:44:20 +08:00
关键还是水货包太多了
|
20
lonelygo 2019-05-29 02:10:51 +08:00 1
这事情,基本就是:理想丰满,现实骨感,背影还行,转身要命。
|
21
changdy 2019-05-29 08:34:14 +08:00 1
这点没得洗,依赖管理非常不友好.尤其是没有`package-lock`的时候.
然后前端本来也变化多段..跑旧项目的时候别提有多糟心了. |
22
unclemcz 2019-05-29 08:35:13 +08:00
这是最简单粗暴的解决依赖版本问题的办法。
|
23
unclemcz 2019-05-29 08:36:50 +08:00
@changdy 对的,我最开始用 4,那时候还没有 package-lock,后来一次升级到 8 有了 package-lock,感觉世界都晴朗了。
|
24
xg4 2019-05-29 09:19:53 +08:00
还有很多相同的功能的不同模块,被引用到项目中。(轮子太多)
比如判断是否是对象,有 isObj, is-object, isObject 等等,不同的作者可能使用的库都不一样,可能都被下载到我们的 node_modules |
25
lzvezr 2019-05-29 09:26:17 +08:00 via iPhone
版本不同,并不是所有人都爱做向下兼容
|
26
StephenHe 2019-05-29 09:28:12 +08:00
Yarn 会在 c 盘缓存,发现的时候 6 个 G 了。都存一个地方没改目录,恐怕 C 盘马上就爆掉了
|
27
abcbuzhiming OP @KuroNekoFan 请问一下,npm5 到底能不能实现共享的依赖?如何实现?
|
28
abcbuzhiming OP @lzvezr 版本不同没关系啊,我的意思是,难道不能同版本只留一份吗?一个统一的存放目录,xx 框架 1.0,2.0,3.0 各一份,其它项目想引用哪个版本就引用哪个版本啊,为啥非要像现在这样,一个项目下下一次 xx 框架 1.0。换个项目又下一次 1.0 ?
|
29
KuroNekoFan 2019-05-29 09:56:01 +08:00
@abcbuzhiming 只考虑 npm 的话,你可以不使用 npm install,通过手工做软链之类的来把项目依赖链接到你指定的位置,以项目(repo)角度来说,有一些工具可以实现依赖共享比如 lerna(昨天刚好看过一下相关讨论),另外,webpack 本身也可以指定 resolve 的位置。所以说方法有很多,但是共享依赖在很多 corner case 里会带来很多问题,所以 npm 本身的策略是,不共享
|
30
zpf124 2019-05-29 10:28:46 +08:00 2
@KuroNekoFan
我只看到一个提及 jar, 也并没有说 java 如何,那个是在拿 maven 类比, 题主本身就提到了 maven, 然后请百度 maven 是什么, 看看到底谁有 ptsd maven 采用的方式就是 本地一个存储仓库,存放所有下载下来的不同版本的依赖包, 除了编译 build 时会复制项目用到的依赖外,所有的项目里都不会存在完全相同的依赖包. 而且 npm 本身问题一直不少, 比如 namespace |
31
lihongjie0209 2019-05-29 10:32:31 +08:00
@zpf124
还是有明白人啊 |
32
KuroNekoFan 2019-05-29 11:35:05 +08:00
|
33
lzvezr 2019-05-29 11:47:06 +08:00 via iPhone
@abcbuzhiming 现在应该是可以了吧,同一版本只下载一次
|
34
kzfile 2019-05-29 11:53:50 +08:00
多占点地方我无所谓,不出现冲突省事就行.
我倒是一直想,npm 下载下来的包如果是一个 webpack 打包好的独立 js 就好了 |
35
photon006 2019-05-29 12:01:01 +08:00
项目单独安装依赖挺好的呀,python venv 就是这样,毕竟不同项目使用的同一 package 可能是不同版本,所以要单独安装。
如果嫌 npm 安装慢那是自己网络问题,可以用国内淘宝源:npm install --registry=https://registry.npm.taobao.org 或者用 openwrt 路由器彻底解决网络问题。 |
36
xihefeng 2019-05-29 12:02:18 +08:00
|
37
xihefeng 2019-05-29 12:09:47 +08:00 1
再补充一个 https://www.zhihu.com/question/41409670?sort=created
Java 在 20 年前就解决这个问题了,然后后面抄的语言没有一个完全抄对的 |
38
azh7138m 2019-05-29 12:35:57 +08:00 3
@xihefeng 不会改进
而且其他包管理器早晚会在每个项目本地搞一个依赖目录的(滑稽 npm 在这里试图解决的问题是 当你的项目 P 存在依赖 A、B、C、D 时, P 依赖 D@1 A 依赖 D@2 B 依赖 D@3 C 依赖 D@4 这种问题是要考虑的 这里能优化的是两个场景 - 一个是已经被 yarn 和 npm 做掉的,一个项目内对一个依赖有多次依赖的时候,会尽量 resolve 到同一个版本(其实新版 npm 做的比 yarn 好,能让 node_modules 更扁平,但是带来了更多的问题(滑稽 - 另一个是楼主说的 不同的项目对一个依赖要求的版本相同的时候,能不能只存一份 后面这个有点尴尬,依赖是往上不断找 node_modules 的,按道理是可以做一个 "根 node_modules",但是 P1 P2 依赖 D@1 P3 P4 依赖 D@2 要怎么处理呢? symlink 也不行,webpack 的 resolve.symlinks 可以使用文件的真实路径,如果这么搞,算是 break change,非常僵硬。 或者就等,真 break change,PnP 上线吧,完全由 js 来控制 resolve 依赖的行为,新的依赖布局不需要过多考虑兼容性,能有更多的操作空间。 |
39
libook 2019-05-29 12:45:48 +08:00 1
不黑不吹,也不说无关的事。
有人喜欢放在统一的目录里,有的人喜欢相互隔离,事实上确实不同应用场景下有不同的需求,不能说哪一种绝对好;工具只能提供一种默认方案(两种就不叫默认了),但工具也可以提供足够的灵活性来让人们自助解决需求差异。 Node 对与 node_modules 的搜索是有一个规则的,规则不满足需求也可以用 NODE_PATH 机制来指定,可以结合一些 Npm 的指令以及自动化脚本来 Hack 出一个基于 Npm 的集中包管理机制。 Npm 并不是 Node modules 的唯一管理工具,pnpm 就可以提供“ One version of a package is saved only ever once on a disk.”的特性。 实现整个系统环境或用户环境有一个共享的包目录所遇到的问题,肯定比实现每个项目下有一个包安装目录遇到的问题要复杂。举个例子,要删除一个包或一个版本的包的时候,肯定是基于一个项目的需求来删除的,但共享目录是所有项目都在用的,那仅当只有这一个项目依赖这个包的时候才可以删除这个包,这有点类似垃圾回收机制。类似的问题肯定是可以有解决方案的,只不过也一定是需要额外的成本的,将一个项目的问题封锁在项目目录内,相当于是将包管理的问题降维,这可能是 Npm 一直在用这个方案的一个历史原因。 对于 Node 服务开发来说,依赖包占用空间多的情况较少,问题主要集中在网页开发方面,这个其实不是 Npm 的锅,主要是现在网页开发应用的语言太多,每种都需要特定的编译程序的支持,比如 JSX、Vue、Sass、TypeScript 等等,空间占用大,编译时间长,最终生成的网站大小并不大(否则就会有流量问题和加载性能问题了)。 所以建议根据项目的具体情况来选择包管理方案。 |
40
lqzhgood 2019-05-29 12:46:07 +08:00
嗯。。。 我觉得硬盘不值钱呐。 那就用最简单的办法 node_modules 嵌套处理包依赖吧。
如果 node_modules 名字是 a 开头如 a_node_modules 就更好了~ 还能防 rm -rf .... 逃~~ |
41
mritd 2019-05-29 13:39:12 +08:00
@WittBulter #15 这不是我说不用就不用的问题,我记得很清楚,当时是一个 sass 的某个版本,智障的去下载 Github 的东西,然后 404 ;国内线上机房的网络大家都懂,本身链接 Github 就慢的要死,实际 Relese 版本还被作者删了;像 sass 这种东西生产级的项目你没法说不用就不用,就我目前做 Devops 来说,直接让前端换这种级别的东西有点过了
CI 现在都没法处理这个 node_modules,你说你 cache 整个目录,本身就贼鸡儿大就不说了,每个项目还一个; CI cache 时还会做压缩处理,里面全是海量小文件,有时候都可能出现文件名超出文件系统限制;你 cache npm、yarn 的哪个 cache 目录吧,有些包还特么自己联网下东西;就算不联网下载的你 cache 住了,你会发现 npm install 仍然会进行一个很长时间的编译动作,极大拖慢 CI build 时间 |
42
KuroNekoFan 2019-05-29 13:50:32 +08:00 via iPhone
@mritd node-sass,老大难了,但是算作 npm 的问题是不合适的
|
43
liuhuansir 2019-05-29 16:32:23 +08:00
每个项目都有个 node_modules,多了之后在 win10 上会出现我的电脑显示“处理中”,导致 explorer 卡住,只能重启解决,node_modules 里面小文件太多了
|
44
abcbuzhiming OP @azh7138m 等一下朋友,我搜索资料过,说 NPM 现在已经能把依赖树扁平化了,只要依赖树扁平化,为何不能一个版本只存一份呢。你说的那些问题,如果 NPM 的扁平化依赖方式能处理,那么,只存一个位置——不管它放在哪里,都是毫无问题的。除非 NPM 的依赖扁平化也解决不了你说的:
P1 P2 依赖 D@1 P3 P4 依赖 D@2 你说的这个问题其实就是依赖不同版本,为了避免冲突,不得不用本地存放的方式来生成一个嵌套树 所以现在我感觉大家的回答很矛盾。我想问的是能不能“全部依赖放在集中的位置,一个版本只留一份”。而大家回答的是因为历史原因,容易出现依赖一个库但是版本不同的原因,为了应对这个问题,必须使用嵌套树存放,好像嵌套树才是 npm 必须使用本地目录存放依赖的根本原因。但是又有人回复我说 NPM 已经解决了这个依赖嵌套树,一级套一级问题,实现了依赖树扁平化——但是只要依赖树扁平化了,那实际就是一个版本只放一份吧。这等于说 NPM 依赖处理是可以实现集中存放的。还是说 NPM 的依赖扁平化并不是适用所有场景的?前套树在某些情况下还是得存在 |
45
lincanbin 2019-05-29 16:40:07 +08:00
空间换便利
|
46
liuhuansir 2019-05-29 16:46:00 +08:00
@abcbuzhiming 我查的资料是部分解决了嵌套问题,比如 A,B 同时依赖 C@1,那 C@1 不需要嵌套,如果 A 依赖 C@1,而 B 依赖 C@2,则还是以前的老办法
|
47
HiCode 2019-05-29 17:15:29 +08:00
接手过一个 node.js 写的 H5 小项目,整个项目代码大小 400MB ……
本来想凑合着用的,后来实在受不了,改用 PHP 重写,世界都清净了!!! node 这样的玩法,我看不长久啊……(个人看法,不喜勿喷) |
48
azh7138m 2019-05-29 17:20:34 +08:00
@abcbuzhiming > 只要依赖树扁平化,为何不能一个版本只存一份呢
是啊,这是两个场景 - 同一个项目 - 多个项目 对于第一种,各种管理器会尽可能的 resolve 一个依赖到同一个版本,如果可以,可能就会直接放置在项目的 node_modules 下面,哪怕它是依赖的依赖,不能的那些,还是会和原先一样,黑洞式放置 这里说到了 "尽可能的 resolve 一个依赖到同一个版本",如果本身就是写死了不同的版本,那么包管理器也是无能为力的。 对于第二种,历史包袱也在,版本冲突问题无法妥善解决。 上面说的问题都是,需要考虑兼容性的,如果是自己的项目,没有兼容性考虑,是完全可以实现 所有项目公用依赖 的。 扁平化,不是说完全扁平化,上面说了,是"尽可能的 resolve 一个依赖到同一个版本",本身声明依赖的版本就不同,(包管理器)是没有办法处理这种情况的。 最后,希望大家可以看下 PnP,以及社区围绕新的依赖布局的讨论,这些问题都是被讨论很多次了。 |
49
HiCode 2019-05-29 17:24:08 +08:00
建议 node 学 php 一样,大量常用函数直接内置,或者推动一两个标准“库”成为官方标准,我记得是有这样的库的。
现在大量 node 的项目引用成千上万个库,这些库又引用其他库,真当每个开发者的电脑都是顶配?真当开发者的时间、网络、硬盘不用钱? 有段时间确实想试试直接用 node 解决后端的,试了一下果断放弃,node 这玩意还是留给前端精英们去玩。反正学多一门语言( php、python、lua ……)又不难。 |
50
MissThee 2019-05-29 17:29:23 +08:00 via iPhone
@karnaugh 虽说是存一份儿,1.x 和 2.x 不能分开两个文件夹存嘛,各项目用配置的版本号各取所需
|
51
sodatea 2019-05-29 21:43:14 +08:00
Yarn Plug'n'Play 和 pnpm 可以了解一下,他们都是在试图解决这个问题
|
52
ericgui 2019-05-30 03:11:30 +08:00
老铁,你是没用过 python 吧? python 就是全局安装,后来用了个 virtualenv 来解决全局安装的问题
每个项目单独安装一下,你觉得不方便是因为你的网速太烂,这个没办法 但单独安装,显然是有极大的好处的 |
53
BlackHole1 2019-06-04 22:32:09 +08:00
node_modules 就是智障- -
|