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