背景
对公司组件库进行迭代优化，构建升级是其中重要的一环。原来的构建工具是基于 rollup 以及相关插件实现构建。但在前端工具链快速发展的今天，仍有优化空间。
现有问题
- 构建速度较慢: 在
macOS上构建需要一分钟左右，在 CI 环境下需要更长时间 - 构建配置复杂: 由于
rollup高度的插件化，对比如：模块解析、cjs转换、esbuild提速等都需要单独安装插件，不够简化。 - 面向未来:
vite生态发展迅速，且rolldown作为即将到来的高性能底层打包引擎，未来可期，我们也希望统一成rolldown的生态工具。
为此，我选择了 tsdown 作为新的构建工具，进行重构。
Library 的开发模式
在 monorepo 下开发 Library 时，为了获得良好的开发体验（即代码变更后能即时生效），通常有以下三种开发模式可供选择：
- Watch Mode
- Stub Mode
- DevExports
Watch Mode 通过构建工具监听文件变更，实时构建并输出到目标目录，供其他包引用（常见工具如 vite、tsup、esbuild、rollup 等）。
Stub Mode 是对源码生成一层代理文件（存根），利用 jiti 等即时编译工具对 ts 文件进行实时转译（如 unbuild）。
DevExports 则利用 package.json 中的 exports 字段，将开发阶段的构建入口直接指向源码文件，而生产阶段则指向构建产物。
本文将主要对比这三种模式的优缺点，并分析它们各自适配的使用场景。
🧩 背景
在 element-plus 的 ElSelect 组件中，在禁用状态下，展示的值无法被 focus 选中。
在我的业务场景中，一个大表单的详情是以禁用状态展示，操作人员需要频繁的获取信息，行为上是 focus 输入框或者选择框，ctrl+a+ctrl+c 来复制内容。
在 2.5.0 版本之前，是支持这种能力的，但是在后续版本中，ElSelect 组件结果重构，改变了这一行为。为了既能保持改业务的强需求，又能享受升级的便利性，最好的方式是对组件进行源码处理。
提过 pr 后，官方成员认为当前行为是和原生 select 一致的，不会进行修改。 那就只能自己动手，源码 patch 一下了。
之前在开发一款 Chrome 扩展插件，目标是在 content-script 方式下开发。
既然是直接在DOM页面插入组件，优先考虑样式不会影响页面，所以考虑 使用 Shadow DOM 来隔离样式。
在此场景下开发时，遇到了一些问题和思考，记录如下：
tailwind V4在Shadow DOM下的兼容性问题- vite 下
hmr的问题 - 思考
Tailwind V4
基于前不久的项目框架升级和重构，记录一些踩坑和问题；
💡 一句话摘要： 这次升级围绕发布速度、依赖治理、格式化规范化等关键节点展开，从提速到风险控制，都踩过坑也找到了解法。
🧱 背景
- 🚦 项目发布流程缓慢且不稳定，对实际的测试发布效率影响较大
- 📝 格式化没有强制执行，在 codeReview 中会出现大量格式化 diff，review 困难
- 🧟 有大量的幽灵依赖，导致项目体积变大且不易排查问题
- 🧗 升级困难，开发无法享受新技术带来的便利
🎯 探索 Vue 组件自动导入的奥秘
深入 unplugin-vue-components 源码，揭开自动导入的实现原理
在 Vue 项目开发中，我们经常会使用 unplugin-vue-components 这个插件来自动引入组件，告别繁琐的手动 import 操作。
🤔 但你是否好奇过它是如何实现的？
让我们一起拆解一下源码（以 Vite 为例），看看这个"魔法"背后的技术原理～