TD Mono: lock file

[zhangpaopao0609]

你建议的方案是什么

以下内容源于 @uyarn

关于要不要加锁文件的一些想法：
之前为什么不加锁文件的几个原因，

1. library 场景下锁文件锁不了实际的依赖的版本，只能锁住当前组件库开发阶段的依赖，存在组件库开发正常，用户使用时安装依赖发现异常的问题
2. 包管理工具存在多种选择，且此前的包管理工具版本经常发生变动，不同人提交的锁文件经常存在变动，如yarn、npm、pnpm以及他们各自之间存在的版本差异带来的锁文件差异
3. 组件库本身的依赖可以平滑升级，如site-components、icons的更新后可以不更新仓库即完成自动升级，不需要再提交PR
   与此同时也存在一定的问题，也是我们平时维护偶尔遇到的，如某个依赖时不时会出现升级后影响构建或者部署的问题，存在一定的隐患，这个问题改为大仓之后，依赖增多可能会愈发严重，依赖增加且一些是root dependencies，一些是某个workspace的dependencies，排查起来可能难度更大，

以上提到的问题可以考虑配合加锁文件之后的解决方案：

1. 针对问题1，想到一个可以避免的解决方式，组件库本身的dependencies 改为在版本号上就固定版本，不写~/^这种sevmer的版本，如dayjs 不写 ~1.11.10 改为1.11.0，理论上可以解决开发阶段和用户使用的差异问题，
2. 针对问题2，改为pnpm workspace的大仓之后，不存在锁全部统一使用pnpm来维护，理论上这个困扰可以避免，除非出现像pnpm 8和9 这种设计者本身就反常规的breaking change
3. 针对问题3，今年已经增加了一些自动提交PR的workflow，如icons发布之后，可以自动通过CI自动提交PR的方式来修改组件依赖的icons的版本，site-components也同理

[github-actions]

👋 @zhangpaopao0609，感谢给 TDesign 提出了 issue。
请根据 issue 模版确保背景信息的完善，我们将调查并尽快回复你。

[zhangpaopao0609]

关于第一点

我认为这是个伪命题，这种因为依赖版本升级导致开发和使用表现不一致的现象本身就不符合社区标准版本管理（SemVer），不应该出现在正式的 npm 库中，如果出现了，那么问题的责任方不该是使用者（tdeign）,而是依赖库的作者。要知道，SemVer 是一个约定俗成的规范，如果这个规范被打破，那么是不是意味着所有的库，不仅限于 js，只要有依赖，都要锁版本呢？

再来讲讲固定版本后的小劣势

• 对于重复的依赖，用户可能安装多版本
• 对于使用非 pnpm 包管理的用户，极小可能出现嵌套过深

所以我的观点是，没有必要固定版本，因此我保留意见，但也不拒绝

关于第二点

不用担心，packageManager 可以规避这个问题，不会出现 lock 文件不一致的情况，同时还可以在 ci 上额外检查

关于第三点

nice work