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.
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.
24 条回复 • 2024-11-30 14:16:11 +08:00
 |
1
zdw189803631 12 天前
确实一坨
|
 |
2
UltraXiaoZi 12 天前
哈哈，这个我深有体会！ Node.js 的依赖管理有时候真的让人抓狂，特别是遇到那些悄悄改动 API 或者行为的库。NestJS 的版本兼容性坑确实不少，pnpm 虽然速度快，但在依赖冲突提示上真的不如人意。
关于 cache-manager 的 TTL 单位从秒变成毫秒，简直是坑死人不偿命！升级个版本还得逐个去看文档和 Changelog ，不然一不小心就踩坑里了。还有那些库大版本升级就随意改动接口，真想对着他们的 GitHub 疯狂提 Issue ！ 看样子以后还是得在 package.json 里明确指定依赖版本，或者用 lock 文件锁定，不然踩坑的日子没完没了。共勉吧，技术之路就是踩坑填坑的循环😂。 |
 |
3
sch1111878 12 天前
直接固定版本呢?
|
 |
4
pursuer 12 天前
和版本管理机制关系不大。
这个主要还是 JS 这边的库生态的前向兼容做的太差了。 相比较，JS/Web 发展那么久也没把之前的设计失误的特性删掉，比如"==",自动创建 id 等。 |
 |
5
sudodo 12 天前
跟 python 的比呢？半斤八两吗兄弟们？
|
 |
6
qiaobeier 12 天前
又不是不能用[楼上头像]
|
 |
7
crysislinux 12 天前 via Android
ttl 变毫秒这个变动迟早要做的，js 的包对时间的趋势就是统一用毫秒。
|
 |
8
victimsss OP |
 |
9
wu67 12 天前  1
准确的说, 你这是‘第三方包中包’的问题, 跟 node 本身的包管理问题虽然有交叉、但是关联不是特别大.
我手头有个项目还是 nuxt2 的, 根本升不上去 nuxt3 了(除非每个页面手动改改改), 依赖包升了各种炸, node.js 版本也上不去了, 锁死在 16.14.2, 更要命的是这个项目是去年上线的, 不知道还能跑多久不炸, 也不知道那天某个依赖包会彻底爆炸 |
 |
10
3825995121 12 天前 1
一般来说都要遵守在语义化版本（ Semantic Versioning ） 版本号通常采用 主版本号.次版本号.修订号 的格式
主版本号的增加通常意味着重大更新 向后不兼容的更改。可能需要用户修改代码或配置才能使用新的版本 次版本号 次版本号的增加通常意味着功能性更新，但保持向后兼容 修订号 修订号的增加通常用于修复问题（ Bug Fixes ），不会引入新功能，也不会破坏向后兼容 这个版本管理机制有什么关系呢 一般来说 都会锁定前两位置 不会出问题的 |
 |
11
importmeta 12 天前
"upgrade": "npx npm-check-updates -i --format group", 我的项目都会加这一条脚本, 每天上班了就会运行一下, 自己控制升级, 推荐给你.
|
 |
12
mark2025 12 天前 3
@UltraXiaoZi
既然是 major 版本 4 -> 5 ，就说明有破坏性变更。升级之前就需要去看它 changelog 日志啊 |
 |
13
kid740246048 12 天前 2
这跟 nodejs 和 pnpm 都没关系，这应该是包维护者是否遵循 semver ，以及升级依赖的时候是否关注 changelog 的问题。nodejs 的依赖管理是有问题，但不太能理解楼主这个怎么能怪到 nodejs 依赖管理上去
|
 |
14
songyoucai 12 天前
说实话， 这是生态繁荣的一种特征，用任何库之前，都得对它足够的了解。不轻易升级
|
 |
15
GiantHard 12 天前
JS 跟时间相关的 API 确实太弱了，可能等 Temporal.Duration 类型普及了，就不会有库用 number 表示时长了。
https://tc39.es/proposal-temporal/docs/duration.html |
|
17
sudodo 12 天前
java 和 golang 的兼容性就好多了
|
 |
18
EchoWhale 12 天前 via iPhone
这跟 nodejs 没啥关系
|
 |
19
sillydaddy 12 天前 via Android
#10 楼说的很清楚。主版本号升级，通常意味着不兼容。这个平时一定要注意。
不过锁死了主版本，可能会锁死一大批依赖它的库的版本，也挺麻烦。 |
 |
22
chihiro2014 12 天前
我更喜欢 maven 一把梭
|
 |
24
uni 11 天前
这个月刚遇到过 node20 能跑的升到 22 就跑不了了
|
Select Language