大型应用、多人协作、团队多项目开发、等场景增加了前端项目开发的复杂度，需要我们合理运用工程化手段来提效。代码共享是其中一种有效提效措施。只要了解不同方案，我们才能结合业务需要给出最合适的工程化解决方案

业务中使用 Monorepo 组织 应用 和 模块，怎样设计一个共享配置包？ UI 组件库怎么打包？怎么使用原生语言（Rust / C++ / Golang 等）编写的模块包？

# Monorepo学习与实战，各类monorepo脚手架优缺点的对比，rush.js核心优化点学习与项目实践

将大型代码仓库分割成多个独立版本化的 软件包对于代码共享来说非常有用。但是，如果某些更改 跨越了多个代码仓库的话将变得很麻烦并且难以跟踪，并且，跨越多个代码仓库的测试将迅速变得非常复杂。

前言 假设我们有4个项目 electron:使用Electron创建的一个桌面端项目，UI和功能大部分与web一致 web:使用React创建的一个web项目 service:使用Nest.js创建的

这是我一直在进行的对话： “[某些原因]”很长，所以我把它写下来是为了避免一遍又一遍地重复同样的对话。 原因1: 简化组织 使用多个代码仓库的情况，最典型的情况要不是每个存储库有一个项目，要不就是每个

0. 🧉 前言 在最近的项目开发中，出现了一个令我困扰的状况。我正在开发的项目 A，依赖了已经线上发布的项目 B，但是随着项目 A 的不断开发，又需要不时修改项目 B 的代码（这些修改暂时不必发布线上），如何能够在修改项目 B 代码后及时将改动后在项目 A 中同步？ 在项目 …

mono repo 并不是银弹，使用这个架构还是会带来很多问题，无非市面上的工具帮助我们解决了大部分。文章主要聊了聊在没有这些工具的时候我们可能会遇到哪些问题，以及使用这些工具后解决了什么又带来了什么

前言 笔者目前所在团队是使用 Monorepo 的方式管理所有的业务项目，而随着项目的增多，稳定性以及开发体验受到挑战，诸多问题开始暴露，可以明显感受到现有的 Monorepo 架构已经不足以支撑日渐