Refactor/monorepo

[NWYLZW]

🤔 这个 PR 的性质是？

• [ ] 日常 bug 修复
• [ ] 新特性提交
• [ ] 文档改进
• [ ] 演示代码改进
• [ ] 组件样式/交互改进
• [ ] CI/CD 改进
• [x] 重构
• [ ] 代码风格优化
• [ ] 测试用例
• [ ] 分支合并
• [ ] 其他

🔗 相关 Issue

💡 需求背景和解决方案

monorepo 支持。

📝 更新日志

• [x] 本条 PR 不需要纳入 Changelog

☑️ 请求合并前的自查清单

⚠️ 请自检并全部勾选全部选项。⚠️

• [x] 文档已补充或无须补充
• [x] 代码演示已提供或无须提供
• [x] TypeScript 定义已补充或无须补充
• [x] Changelog 已提供或无须提供

[NWYLZW]

一、渐进式迁移。先把整体挪到 monorepo 下面，保证能够运行起来；再依次将各个模块拆出来，分别独立作为单一模块进行发布与依赖管理。 二、common 模块的迁移动作。由于 common 模块的特殊性，我们需要保证 common 的迁移成本尽可能的小，我决定把它作为最后一步来进行。 三、关于类型 tsconfig 的规整化。现有 tsconfig 相对较为混乱，我们需要定义一套可用的 monorepo 的中每一种文件的类型定义。保证相互之前不产生冲突。 四、文档站的迁移。这个需要往后面挪，和构建流程产生一定的依赖关系，需要处理清晰才能正确进行。 五、单元测试的适配。目前单元测试针对于单仓过于依赖，需要改造文件路径的匹配规则。 六、构建流程的调整。如果按照第一步的整体挪动，展示只会涉及到文件路径的变动，调整一下编译发布目标即可。按照后续的模块拆解来看的话，我们需要一个根据依赖关系逐层编译产物。

[github-actions[bot]]

[uyarn]

七、CI的调整 目前特别是发布流程利用了git tag 改成Mono Repo后 这部分也要考虑