基于 pnpm monorepo 项目工程设计，字节框架传授多场景项目架构要诀
你的过往项目中，项目和工程化架构有没有做过，有没有了解 monorepo 框架方案？
传统架构概述
- 组件库、用户中心、脚手架、图表库、工具库
- 独立项目结对，所有项目都是分开的 github 仓库
- 技术栈独立
- 规范化、自动化相关处理是项目间割裂
- 依赖管理，版本本难统一管理
- 部署、docker, docker compose, 自动化脚本很难形成统一
monorepo 框架
- 混合项目结构，所有相关的工程形成子包进行管理
- 技术栈高度集成（团建基础项目、业务项目、子服务、技术栈）
- 规范化、自动化，流量在项目间共享
- 依赖管理，版本本统一
monorepo 架构方案
- 包管理， pnpm pnpm workspace、yarn workspace、lerna
- 构建缓存
- 增量构建，nx、 turbo
pnpm 优势
npm、yarn、cnpm
- 链接机制
- 缓存机制，寻址
- 原生支持 workspace
- 磁盘占用少
中心化思想解决依赖复用问题
传统架构到 monorepo 框架进展
附段1：传统架构基础痛点（主要缺陷）
- 代码分散化，将多个关键项目统一到一个 github 仓库
- 工具引入，pnpm workspace
- CI/CD 重构
附段2：具体的 monorepo 框架
- 公共技术基础设施
- pnpm, turbo，解决子包与主包关系
附段3：自动化的构建流程优化
- 打包方案：vite, webpack, rollup, parcel, sup, esbuild, swc, rollupdown
- 构建流程优化，依赖关系（循环依赖引入），哪些包需要重构构建
- 发布：npm publish, docker 镜像
- 监控和测试
关键性卡点 (步骤)
- 项目统一
- pnpm 配置
- 依赖管理
- 统一化脚本
- 工程化脚本：package.json 中的 script
scripts文件夹
面试上的表述：我主导了工程化架构的重构工作，基于pnpm workspace 统一化工程组织，统一自动化、流程、规范化相关内容，子包管理更清晰基于tsup构建团队基建包，业务架构我主导通过为前端机制来实现，统一化主应用与子应用状态管理细节
组件库、脚手架、业务系统工程化基于 monorepo 架构设计有什么实践经验，详细讲讲？
- 组件库，工具库、图标库
- 脚手架，基于类形态的项目模块
- 业务系统
- 服务端脚手架
负责过项目前期打包构建流程设计么？有了解哪些打包构建方案？（初级）
- babel
- tsc
- rollup、parcel
- tsup
- vite、webpack
typescript compiler编译ts工具,将ts编译成js tsconfig.json
特点
- 专注于ts编译
- 强类型检查
- 单文件编译
使用场景
- 早期项目，没又复杂的编译需求
- 工具类的开发、后端node
缺点
- 仅支持ts编译，常规js编译、类型输出.d.ts
- 不能代码拆分、模块打包
- 性能差，大规模的项目用它编译性能堪忧
- 配置繁琐，tsconfig，有时需要借助babel、postcss编译其他内容
rollup
随着项目的复杂度提高，tsc无法满足需求，这个时候希望有一个开箱即用的0配置，rollup成了工具库的首选构建打包方案
- tree-shaking
- 简化配置，tsc、webpack
- 丰富的插件生态，将功能的生态构建工作交给全世界开发者，框架插件规则制定者
使用场景
- ui库
- 工具库
- 按需导入场景
缺点
- 大型业务项目，vite和webpack适合
- 热更新
- 性能方面
tsup
go,esbuild, tsup
特点
- 零配置，默认支持ts
- 性能非常好
- 多格式输出
- 代码的动态导入
- 代码分割
使用场景
- 工具库
- 脚手架
缺点
- 业务构建不推荐
- 插件生态没rollup繁荣
vite
- 整合了esbuild的rollup的现代构建工具
特点
- 开发环境基于 esbuild
- 按需加载
- 模块替换HMR
- 生产构建rollup
使用场景
- 大型业务系统
- vue、react业务系统
缺点
- 生态
- 低版本兼容 lagecy
- 微信网页开发，本地开发环境，es模块
不同形态前端项目打包构建有什么具体设计思路和实践经验？（中级）
工具库
- 脚手架
- 函数库 选择tsc、rollup、tsup
组件库
选择rollup、tsup
业务系统
选择vite、webpack
站在leader的角度，从原理层面的分析常规与新兴的构建方案异同，详述rust重构工具链的优势？（专家）
技术原理
- 常规的：
- 原理 js，webpack、tsc工具见AST无法共享
- 生态成熟，兼容性
- 性能瓶颈
- 需要突破的是语言
- python、go
基于rust的工具
- swc
- turbo
- oxc
拥抱新兴构建工具的目的
- 性能
- 单线程瓶颈
- 大型项目的收件，webpack4十来分钟
- 统一化
- oxc编译、lint、format
- 内存安全稳定性
- 社区繁荣
除了常规css还有哪些方案？（初级）
- css 简单好理解，复用性底，容易冲突，无法支持动态语法
- sass、less 变量定义、编译处理
- 学习曲线，需要进一步封装，css hack（兼容性、厂商前缀）
- postcss
- css module 和css一样，针对ts类型支持不完善，定制化、复用性高的需求无法满足
- atomic css/utility-first css（tailwindcss）
- 非常快，编译时，对于运行时的开销非常小
- 不写css全部写类名
- cssinjs（style-conponemts、emotion）
- 运行时，无需编译，复用性高
- 运行时的反噬性能差
- scoped css
- 简单好理解，解决冲突问题
- 复用性差
- BEM，写法，不是一个技术 （下划线）
请举例 css、cssinjs、tailwindcss的使用技巧与方案价值体现？（中级）
module css
- 变量复用
- css3 变量 --primary：pink，tokens颜色色值定义
：root{
--color-primary：pink
--bg-primary：white
}
- BEM 命名规范，header-ssdf__sdfsdf
- flex、grid布局
cssinjs
- 动态样式
- 样式隔离，类名自动生成
- 嵌套
tailwind
- 原子化设计，归为类名
