越来越讨厌 nodejs 的版本管理机制

查看 122|回复 12
作者:victimsss   
https://stackoverflow.com/questions/73908197/typeerror-store-get-is-not-a-function-nestjs-cache-manager/76777854#76777854
https://github.com/jaredwray/cacheable/issues/210
以 nestjs 为例,当前服务是 v9 ,想引入依赖的时候,pnpm 也没有提供版本不兼容的提示,只有安装了运行出错了才知道。
顺便吐槽一下,还有多个依赖都有这种情况,好多库 v4 升 v5 改单位了,为啥:
cache-manager version 4 uses seconds for . The current version of (v5) has switched to using milliseconds instead. NestJS doesn't convert the value, and simply forwards the ttl you provide to the library.
zdw189803631   
确实一坨
UltraXiaoZi   
哈哈,这个我深有体会! Node.js 的依赖管理有时候真的让人抓狂,特别是遇到那些悄悄改动 API 或者行为的库。NestJS 的版本兼容性坑确实不少,pnpm 虽然速度快,但在依赖冲突提示上真的不如人意。
关于 cache-manager 的 TTL 单位从秒变成毫秒,简直是坑死人不偿命!升级个版本还得逐个去看文档和 Changelog ,不然一不小心就踩坑里了。还有那些库大版本升级就随意改动接口,真想对着他们的 GitHub 疯狂提 Issue !
看样子以后还是得在 package.json 里明确指定依赖版本,或者用 lock 文件锁定,不然踩坑的日子没完没了。共勉吧,技术之路就是踩坑填坑的循环😂。
sch1111878   
直接固定版本呢?
pursuer   
和版本管理机制关系不大。
这个主要还是 JS 这边的库生态的前向兼容做的太差了。
相比较,JS/Web 发展那么久也没把之前的设计失误的特性删掉,比如"==",自动创建 id 等。
sudodo   
跟 python 的比呢?半斤八两吗兄弟们?
qiaobeier   
又不是不能用[楼上头像]
crysislinux   
ttl 变毫秒这个变动迟早要做的,js 的包对时间的趋势就是统一用毫秒。
victimsss
OP
  
@sch1111878
固定版本的前提是先踩了版本不兼容的坑,因为这是一个新引入的依赖,要么你是事先知道 xx 版本就是兼容

wu67   
准确的说, 你这是‘第三方包中包’的问题, 跟 node 本身的包管理问题虽然有交叉、但是关联不是特别大.
我手头有个项目还是 nuxt2 的, 根本升不上去 nuxt3 了(除非每个页面手动改改改), 依赖包升了各种炸, node.js 版本也上不去了, 锁死在 16.14.2, 更要命的是这个项目是去年上线的, 不知道还能跑多久不炸, 也不知道那天某个依赖包会彻底爆炸
您需要登录后才可以回帖 登录 | 立即注册

返回顶部