karloku

@fuxkcsdn 自托管的 gitlab 社区版和企业购买 gitlab 企业版不冲突. 社区版的参与度高了对于企业版来说反而可以得到更多的代码反哺. 这是大部分 foss 项目基金会商业运作的模式, 通过放置在上游的社区版蹭社区的开发力量, 然后利用企业版的授权和支持来赚钱.

当然如果用户最后选择涌进 gitlab.com, 把这个官方的托管平台变成下一个 github.com, 那只能说用户咎由自取.

@patrickyoung 原文提到了. 既然公司宣称拥抱 FOSS, 就应该提供完全 FOSS 可自托管的代码库.
商业公司赚钱无可厚非, 一边打情怀假装自己拥抱 FOSS, 一边又是只提供基于完全闭源代码版本的中心托管平台.

现在的微软特别喜欢一边说着拥抱开源热爱社区, 一边建立自己一言堂的社区规则方便商业化整个社区的贡献.

作为其他语言用户确实困扰了
但是按 10 是 number 的一个子类大概理解一下觉得这个才直觉. 宽引用转换到窄必须显式转换并且最好有相应的异常处理. 不然谁能保证 x: number 一定是符合 10 的

丢失 collection 不至于.
就算古早的 mongodb 会丢数据, 但那也是 2.0 以前的默认配置下, 写入数据不需要 ack 时期的事情了.

venv 最有安全感, 配合 dotenv 一起用也没什么不便利的地方

如果优化不了条件的话, 可以设计成能提前进行 return/continue/break 的执行方式

当然最好是想办法优化一下判断条件, 这么长的判断式可读性很差

都可以, DTO 看起来帅一点也更符合本身单词的逻辑, 但是对自动转换驼峰和蛇形的反射器不太友好. 取舍以后保持一致就行.

@Cielsky 锁包了就没事. npm i 时生成 package-lock 都是默认选项了, 用 npm ci 能保证按照 package-lock.json 里的依赖进行安装.
而且 npm i 也只会在发现写在 package.json 里的项目有新版本时更新 package-lock.json. 非库项目不要用 ^ 指定依赖版本, 应该直接指定确定的版本号. 这样只有手动升级的时候才会导致 lock 变更, 可以进行测试.

@2i2Re2PLMaDnghL 对, 我意思 MIT 就只要求写个 "Copyright Notice" (翻译: 冤有头债有主(