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 来隔离样式。

在此场景下开发时，遇到了一些问题和思考，记录如下：

1. tailwind V4 在 Shadow DOM 下的兼容性问题
2. vite 下 hmr 的问题
3. 思考

Tailwind V4 ​

基于前不久的项目框架升级和重构，记录一些踩坑和问题；

💡 一句话摘要： 这次升级围绕发布速度、依赖治理、格式化规范化等关键节点展开，从提速到风险控制，都踩过坑也找到了解法。

🧱 背景 ​

• 🚦 项目发布流程缓慢且不稳定，对实际的测试发布效率影响较大
• 📝 格式化没有强制执行，在 codeReview 中会出现大量格式化 diff，review 困难
• 🧟 有大量的幽灵依赖，导致项目体积变大且不易排查问题
• 🧗 升级困难，开发无法享受新技术带来的便利

在 Vue 项目开发中，我们经常会使用 unplugin-vue-components 这个插件来自动引入组件，告别繁琐的手动 import 操作。

🤔 但你是否好奇过它是如何实现的？

让我们一起拆解一下源码（以 Vite 为例），看看这个"魔法"背后的技术原理～

一些脚手架基础配置 ​

• vscode settings
• eslint -v9
• eslint -nuxt -v9
• commitlint
• husky
• lint-staged
• 自定义eslint 规则

概念 ​

微前端是一种架构风格，它将一个大型的前端应用拆分成多个独立的微应用，这些微应用可以独立开发、部署和维护。微前端的目标是将一个复杂的前端应用拆分成多个小的、可独立开发和部署的应用，从而提高开发效率和应用的可维护性。

在实际场景中，我们常常需要再当前主应用，嵌入某个子应用，就不必自己开发，子应用可能有别的业务部门开发，技术栈亦不一致。