V2EX › Ketteiron 的所有回复 › 第 10 页 / 共 30 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 6 7 8 9 10 11 12 13 14 15 ... 30

❮

❯

2025 年 10 月 22 日

回复了 COW 创建的主题 › 云计算 › 防止云厂商绑定是怎么做的？

@COW #34 不同厂家的 FaaS/Serverless 的触发器、API 、SDK 、Runtime 都不一样，上多云约等于全部重写多次。函数是无状态的不代表没有平台依赖性。
https://github.com/serverless/serverless/issues/9583

2025 年 10 月 22 日

回复了 COW 创建的主题 › 云计算 › 防止云厂商绑定是怎么做的？

多云架构，抽象与实现有很多种，多活/双活/热备/温备/冷备等。
双活/多活就是多个云上都准备好了服务，方便某个厂商拉跨时迅速撑起流量。
冷备份是以单个云作为主力，出现灾害时通过自动化流程临时去其他云买/租机器然后迁移服务。
热备/温备介于二者之间。
但想法是理想的，现实是。。。
99.999%服务并不会因提高可用性而提高实际可用性，反而引入了更多的复杂度。

2025 年 10 月 22 日

回复了 zhouyin 创建的主题 › Go 编程语言 › golang.org/x/sync/syncmap 被 struct 裹挟时使用前为什么必须为每个键初始化不然取值得到 nil

值接收者会强制复制值，这应该知道吧。
简单来说，sync.Map, sync.Mutex 不能被复制，在你这个用例中，读和写是不同的 map 实例。

2025 年 10 月 21 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

@wangtian2020 #53 这确实不容易实现，特别是有 cjs 这个历史包袱，直到最近这两个差不多可以真正互操作，除了一些比较罕见的用例。
https://joyeecheung.github.io/blog/2024/03/18/require-esm-in-node-js/
理论上委员会宣称 esm 为标准时，就应该逐渐放弃 cjs ，但直到 2025 年依然还是 cjs first 。
不过我对 deno 和 bun 的未来不太看好，当 cjs 名义上死亡后，deno 和 bun 用户大概又会迁移回来，虽然这可能会花费十年到无数年。

2025 年 10 月 21 日

回复了 MiHwAppleTslFan 创建的主题 › 生活 › 说说我认识的两个男性的生活

你这个标题有很大的问题。

2025 年 10 月 21 日

回复了 LonnyWong 创建的主题 › 开源软件 › 发现有些人开源的格局很低，有嘲讽英语的，有嘲讽分享的…

给个建议，用户会自己去 Github 搜索，如果你想增加 mosh 用户看到你项目的概率，你的项目简介里最好包含 `Mobile Shell`

2025 年 10 月 21 日

回复了 luckyc 创建的主题 › 信息安全 › edge 打开 https://www.amazon.com/报病毒?

误报吧，sass 也被误报过
https://github.com/sass/dart-sass/issues/1930

2025 年 10 月 21 日

回复了 Ketteiron 创建的主题 › 程序员 › 2025 年了， express 还在被 "DDOS"

@twofox #5 看看你的 commit

2025 年 10 月 21 日

回复了 Ketteiron 创建的主题 › 程序员 › 2025 年了， express 还在被 "DDOS"

@CHTuring #11 这下兼任终身客服了

2025 年 10 月 21 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

@aleviosa #49 OP 的问题在于 TS 是先支持 '.js' 然后才支持 '.ts' 的
更准确地说，nodenext 要求 import ts 文件使用 '.js'，此时是 2022 年 5 月，nodejs 团队觉得这样的做法是错误的；然后推出新的 bundler 选项和 allowImportingTsExtensions 标志，可以选用无扩展名或者 '.ts'，此时是 2022 年 11 月；然后推出 rewriteRelativeImportExtensions 来支持多平台的使用，此时已经 2024 年 11 月了。

2025 年 10 月 20 日

回复了 Ketteiron 创建的主题 › 程序员 › 2025 年了， express 还在被 "DDOS"

@cochlea #3 ？机器人吧你😅

2025 年 10 月 20 日

回复了 LonnyWong 创建的主题 › 开源软件 › 一个 github 开源的 issue 十多年没有解决，另一个新生的同类项目解决了，在 issue 里回复了一条消息被隐藏，大家如何看？

@wysnxzm #33 我倾向于 issues 是用于跟踪项目问题的，解决与项目代码无关的使用者问题换 discussions ，或者有些 repo 会提供 discord 专门用于解决这些问题。
这是我认为用得好的示例之一
https://github.com/privatenumber/tsx/issues/96#issuecomment-2435160489

2025 年 10 月 20 日

@studyingss #17 如果你觉得使用另一个软件替换掉当前软件是个解决办法的话，issue 很早就推荐 https://github.com/MisterTea/EternalTerminal
mark as spam 的一个重要原因，可能是因为编程语言、协议都不一样吧，我觉得相关人员时隔数年收到个 another mosh 的评论，点进去看了下跟 mosh 无关，觉得这是垃圾信息合乎情理，或许不这么说就不会被隐藏了。
issue 回复也说明了为什么这个功能不会添加，以 mosh 项目的立场去考虑这是合理的，有相应需求的用户应该更换软件而不是期待 mosh 实现它。mosh 团队 open issue 十多年也是错的，正确做法是直接 close ，不要让用户保持无意义的期待。
https://github.com/mobile-shell/mosh/issues/337#issuecomment-9665054
https://github.com/mobile-shell/mosh/issues/337#issuecomment-469768759
https://github.com/mobile-shell/mosh/issues/337#issuecomment-1693794943

2025 年 10 月 20 日

如果没有借鉴的意义，隐藏为离题没什么问题。
举个例子，某个 issue 说 react 有严重的性能问题，然后低下回复 vue 很快。如果是可移植的，或者有借鉴的意义，那才应该提出来。

2025 年 10 月 19 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

@nomagick #38 稍微研究了一下，确实很蛋疼
https://github.com/nodejs/node/issues/52697
https://github.com/nodejs/node/issues/55782
更蛋疼的是目前依旧需要为 cjs 浪费大量人力，而 cjs loader 看起来越来越好
https://github.com/nodejs/node/issues/52219
esm loader 确实需要重构(顺便重构成以 C++ 为主)，但阅读了相关 issue 几乎可以下结论——除非不再支持生态中的 cjs ，不然重构无法开头，有点理解你说的永远翻译成 cjs
https://github.com/nodejs/node/issues/50356
如果不准备放弃对 cjs 的支持，esm loader 理论上无法进行有效重构，且 nodejs 团队其中的一部分人员在 v24 依旧认为 cjs 不应该被放弃
https://github.com/nodejs/node/pull/57460
顺便还发现了 typescript 也放弃了 esm-only
https://github.com/microsoft/TypeScript/pull/58419

2025 年 10 月 19 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

@nomagick #23 很多项目已经逐渐完全放弃 cjs ，也不提供 cjs 产物，全面转向 esm 是必然的事。
这跟 esm loader 没多大关系，主要是几万个 package 一开始不愿意支持 esm ，毕竟它还能跑对吧。
有些库作者激进地 esm-only ，用户又要问为什么不支持 cjs ，这十年是用户与作者们在拉扯，nodejs 对此是没什么办法的。
esbuild 之类的工具尽量解决历史遗留问题，nodejs 没必要重新实现一遍，因为未来某个时间点会放弃 cjs 。

2025 年 10 月 18 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

另外现阶段还是建议用 tsx(不是 react 的那个 tsx) 运行 ts 文件，直到 nodejs 没有这些问题了再说。

2025 年 10 月 18 日

回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？

tsc 虽然能编译成 js ，但这不是它该干的活，毕竟它只是老老实实地把 ts 翻译成 js 没有任何优化，tsc 用来检查类型就行了。
我的做法是 "moduleResolution": "bundler"，后端使用 tsup/tsdown ，前端使用 vite 。
虽然官方推荐显示指定扩展名，但说实话完全没必要，未来真有必要也可以写个脚本全加上。

1 ... 6 7 8 9 10 11 12 13 14 15 ... 30

❮

❯