#优质博文 #前端 #AI #工程化 #bun #新动态
Bun 被 Anthropic 收购。
Bun is joining Anthropic

AI 摘要：Bun 宣布被 Anthropic 收购，将作为 Claude Code、Claude Agent SDK 等产品的核心基础设施。Bun 保持开源与 MIT 许可证，团队与路线图不变，继续专注于高性能 JavaScript 工具和 Node.js 兼容性建设。此次加入为 Bun 带来长期稳定性与更充足资源，也让团队处于 AI 编码革命的前线，加速产品迭代，助力 AI 驱动的开发模式未来。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 加入 Anthropic 的背景与不变之处
• Anthropic 收购 Bun，旨在让其成为 Claude Code 与未来 AI 编程工具的运行基础。
• Bun 将继续开源（MIT 许可）、在 GitHub 公开开发，保持原团队管理与代码维护。
• 路线图不变，持续聚焦高性能 JavaScript 工具与 Node.js 替代能力。

2. 与 Anthropic 合作后的变化
• 更紧密参与 Claude Code 与 Claude Agent SDK 的性能优化，让工具更快更轻。
• 获得 AI 工具一手开发动态，Bun 能优先适配未来 AI 编程需求。
• 加速发布周期，强化生态深度。

3. Bun 的起源与演进
• 起点是开发浏览器 voxel 游戏时的性能瓶颈，促生对编译与运行时系统的探索。
• 从 esbuild 移植 JSX/TypeScript 编译器到 Zig，用 JavaScriptCore 构建自有运行时。
• 2022 年发布 Bun v0.1，集打包器、编译器、运行时、测试与包管理于一体。
• 后续版本：
• v1.0（2023 年）正式稳定，融资并扩张团队；
• v1.1 补齐 Windows 支持；
• v1.2 强化 Node.js 兼容与扩展数据库客户端；
• v1.3 加入前端开发服务器、Redis/MySQL 驱动，生产应用激增。

4. AI 编码工具的崛起与契合
• 2024 年后 AI 编码工具突飞猛进，Bun 的单文件可执行特性非常适合 CLI 与 Agent 分发。
• Claude Code、FactoryAI、OpenCode 等关键 AI 工具均基于 Bun。
• 团队自用 Claude Code 实现自动提交与错误修复，提升开发效率。

5. 可持续性与发展方向
• Bun 至今无直接营收，原计划构建云产品，但 AI 生态发展已重塑商业逻辑。
• 加入 Anthropic 避免了 VC 变现压力，转而获得长期稳定支持与核心地位。
• 与其在未来 AI 开发趋势之外摸索，不如进入中心参与制定。

6. 未来展望与愿景
• 目标成为 AI 时代的标准运行时，让 Bun 承载“AI 驱动软件开发”的基础层。
• Anthropic 为其提供长期资源、战略支持与招聘扩展。
• 持续对社区开放、保持 Node.js 兼容、加速工具链性能提升。
• 预期形态类似「Claude Code <> Bun」关系，类比于「Chrome <> V8」等组合。

author Jarred Sumner

Bun

Bun is joining Anthropic

Bun has been acquired by Anthropic. Anthropic is betting on Bun as the infrastructure powering Claude Code, Claude Agent SDK, and future AI coding products & tools.

#优质博文 #AI #工程实践 #ClaudeCode #工程化
非常好文章，在 X 上的 yousa：“我把前几天在Trae的分享整理成了文字稿“ 里看到的。

yousa (@y0usali): 我把前几天在Trae的分享整理成了文字稿
「https://yousali.com/posts/20251124-how-to-coding-with-ai/」
这篇文章写给已经在或准备在真实生产项目里用 AI Coding 的后端 / 全栈工程师和技术管理者。
它不会教你「按钮在哪里」「哪个 prompt 最神」，而是想在大约 15 分钟里，帮你搞清楚三件事：
哪些任务交给 AI 最「划算」；
怎么让项目本身变得更「AI 友好」，提高一次命中率；
当生成不再是瓶颈时，工程师应该如何设计验证流程，把时间花在真正值钱的地方。

从「写代码」到「验代码」：AI 搭档写走 3 年，我踩出来的协作路线图

AI 摘要：作者总结三年 AI 编程经验，指出 AI 写代码的时代关键不在「准不准」而在「值不值」。文章从个人与团队两个视角分析了 AI 生成代码的最佳使用场景（高重复、低风险、易验证）、如何构建「AI 友好」项目，以及工程师心态从「写代码」到「验代码」的转变。核心结论是：生成已不再是瓶颈，验证才是新的核心；AI 的上限取决于给它的上下文（Context）。标准化与自动化是让 AI 值得信赖的关键，而工程师应成为定义任务与设计验证系统的「总工程师」。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 两种声音与早期弯路 —— 从试验到思考
• AI 编程存在两极化认知：「神迹」与「玩具」并存。
• 初期盲目尝试，成功靠运气，暴露问题在于目标定义不清。
• 结论：关键在于明确「让 AI 干什么」，而非讨论「准不准」。

2. 从关注准确率到计算性价比 —— 「甜点区」的发现
• 引入「效率增益」公式衡量 AI 协作的价值。
• 四类高性价比任务：高重复、高耗时、低风险、易验证。
• 案例：模块化模板 + few-shot 示例提升生成质量。
• 心态转变：接受 AI 错误，注重系统级可靠性。
• 工程协作比喻：把 AI 当成「聪明但不熟悉项目的实习生」。

3. 团队视角的优化 —— 让项目更「AI 友好」
• 数据显示企业中 20%–30% 新代码由 AI 生成，但效率提升有限。
• 关键差异在于：项目是否标准化与自动化。
• 标准化**：统一接口规范、术语表、文档说明，让人机共享上下文。
• 自动化：降低验证成本，AI 助力 pre-commit、自动测试、CI/CD 等流程。
• 实践公式：讲清规则 → AI 辅助执行 → 人专注高价值审查。

4. 工程师的心理负担与注意力管理
• 高频切换任务使「注意力成本」爆炸，人类像「上下文很小的 LLM」。
• 心流（flow）被碎片化交互打断，导致疲惫与效率下降。
• 自救方法：时间分层、AI 时分复用、三分钟原则、沟通卫生与单线专注。
• 重点转移：保护注意力等于提升系统整体吞吐。

5. 稳定的两条工程原则
• 原则一：生成已非瓶颈，验证是核心
• 聚焦测试、监控、回滚机制。考核应基于 Bug Lead Time 而非代码量。
• 原则二：上下文为王（Context is King）
• 上下文完整度决定 AI 产出质量。
• 推广路径：统一规范 → 写进仓库 → 自动化验证。
• 单句箴言：AI 写代码的水平 = 你提供上下文的水平。

6. 给三类读者的建议
• 新手：从小型任务切入，先找「值不值」感受。
• 重度用户：从优化上下文与验证流程入手。
• 管理者：亲自尝试，引导从「个人提速」走向「团队工程化」。

author yousa

🧵 Thread • FixupX

yousa (@y0usali)

我把前几天在Trae的分享整理成了文字稿
「https://yousali.com/posts/20251124-how-to-coding-with-ai/」

这篇文章写给已经在或准备在真实生产项目里用 AI Coding 的后端 / 全栈工程师和技术管理者。
它不会教你「按钮在哪里」「哪个 prompt 最神」，而是想在大约 15 分钟里，帮你搞清楚三件事：

哪些任务交给 AI 最「划算」；
怎么让项目本身变得更「AI 友好」，提高一次命中率；
当生成不再是瓶颈时，工程师应该如何设计验证流程，把时间花在真正值钱的地方。

#优质博文 #前端 #CSS #动画 #工程化 #规范 #course
Keyframes Tokens: Standardizing Animation Across Projects — Smashing Magazine

AI 摘要：本文介绍了通过将动画关键帧 (@keyframes) 设计为可重用的 Keyframes Tokens，来实现动画系统的标准化与可维护化。作者说明了动画重复定义与全局作用域冲突带来的问题，提出以集中式样式表、命名空间、可定制的 CSS 自定义属性（custom properties）和设计 tokens 的方式来统一所有动画。文中展示了 fade-in、slide-in、zoom、spin、pulse 等动画的动态实现，并讨论了动画叠加、组合 (animation-composition)、可访问性 (prefers-reduced-motion) 与实际项目实施策略。核心思想是：让动画像颜色、字号、间距一样成为可管理的系统资源。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. 动画混乱的根源
• 各组件独立创建重复的 @keyframes，导致代码冗余。
• CSS keyframes 属于全局作用域，容易被后加载样式覆盖。
• 修改或统一动画需全局搜查，影响维护效率。

2. 统一的解决方案：Keyframes Tokens
• 将动画关键帧集中存放在共享样式表中，形成唯一数据源。
• 利用命名空间（如 kf- 前缀）避免命名冲突。
• 借助 CSS 自定义属性实现动态参数化，支持多场景适配。
• 使动画定义与其他 design tokens（颜色、间距等）协同管理。

3. 构建基础动画库
• Fade In：定义基础淡入动画并统一调用。
• Slide In：通过自定义属性 --kf-slide-from 控制入场方向。
• Zoom：用 --kf-zoom-from/to 实现双向缩放。
• Spin/Pulse：封装连续动画，可控制旋转幅度、脉冲强度。
• Bounce/Elastic：展示复杂缓动（easing）动画封装方法。

4. 动画组合与冲突处理
• 可将多种动画组合，如 fade+slide 或 zoom+pulse。
• 对同一属性冲突时使用 animation-composition: add; 合并动画效果。
• 适当使用动画时间错位（stagger）提升视觉节奏。
• 说明 transform 与单独变换 (translate/scale) 的执行顺序差异。

5. 无障碍与减弱动效（Reduced Motion）
• 利用 prefers-reduced-motion 提供无动画或柔和过渡版本。
• 对需要仍然变换属性的动画定义瞬时完成（instant-in）版本。
• 保留必要动效但平滑化运动，提升可访问性。

6. 实施策略与最佳实践
• 渐进引入：从常见动画（fade、slide）着手。
• 命名规范：统一前缀标识 token 动画。
• 文档化：在 token 文件添加注释说明用途与参数。
• 灵活性与简洁性：仅暴露必要自定义属性。
• 融入设计体系：将 keyframes tokens 视为 design language 的一部分。

author Amit

Smashing Magazine

Keyframes Tokens: Standardizing Animation Across Projects — Smashing Magazine

Animations can be one of the most joyful parts of building interfaces, but without structure, they can also become one of the biggest sources of frustration. By consolidating and standardizing keyframes, you take something that is usually messy and hard to…

#优质博文 #前端 #性能优化 #监控工具 #工程化
Effectively Monitoring Web Performance — Smashing Magazine

AI 摘要：本文系统阐述了如何制定一套有效的网站性能监测策略，从 Google 的核心指标 Core Web Vitals（包括 LCP、CLS、INP）出发，结合合成测试（Synthetic test）与真实用户监测（Real User Monitoring, RUM），构建可持续的性能优化循环。作者提出“识别 → 诊断 → 监控”三步法，强调在持续对比与回溯的过程中找出性能瓶颈，利用工具如 DebugBear 完成检测与验证，实现网站在用户端和技术端的双重优化。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 网站性能指标基础
• 无单一定义性能标准，推荐从 Google Core Web Vitals 入手，包括 LCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、INP（Interaction to Next Paint）。
• 除核心指标外，还需分析技术层面指标（如服务器响应时间、页面体积），并可利用 User Timing API 自定义关键加载节点。

2. 合成数据与真实用户数据（Synthetic vs Real User Data）
• 合成测试环境可控，便于重现和分析性能问题。
• 真实用户监测基于实际访问数据，可洞见不同用户群体的真实体验。
• 建议双管齐下：Synthetic 提供细节层面的技术分析，RUM 补全真实使用场景的覆盖。

3. 三步法优化流程
• Identify（识别）：通过用户数据发现加载缓慢页面，优先处理高访问量且体验差的页面。
• Diagnose（诊断）：分析瓶颈点，按指标类型分别使用 RUM 或 Synthetic 工具定位问题来源，如 LCP 图像加载、INP 交互事件延迟。
• Monitor（监控）：建立持续检测机制，监测变更效果并在性能回退（Regression）时即时响应。

4. 深入分析阶段
• 负载时间调试：Synthetic 数据帮助精确定位加载瓶颈，可做实验验证优化方案。
• 交互延迟诊断：RUM 数据揭示实际用户交互的慢响应来源，例如脚本阻塞或后台任务负载。

5. 性能回退检测与应对策略
• 合成数据回退：通过前后 Test 对比结果，定位资源变更带来的性能波动，例如新增图片竞争带宽。
• 真实用户回退：需区分访客来源变化（如广告流量）与技术改动，通过分析 LCP/INP 子部分（subparts）锁定性能劣化来源。

6. 综合结论
• 单次测试仅是起点，持续的性能监控体系才能确保长期高效。
• 工具如 DebugBear 可整合 Synthetic 与 RUM 数据，实现可视化性能追踪与优化决策。

author Matt Zeunert

Smashing Magazine

Effectively Monitoring Web Performance — Smashing Magazine

There are lots of tips for [improving your website performance](https://www.debugbear.com/blog/improve-website-performance?utm_campaign=sm-10). But even if you follow all of the advice, are you able to maintain an optimized site? And are you targeting the…

#优质博文 #前端 #JavaScript #工程化
硬核好文，还是很棒的交互式。
The Inner Workings of JavaScript Source Maps

AI 摘要：本文系统解析了 JavaScript 中 Source Map 的内部机制，从 TypeScript 构建流水线到 Source Map 的 JSON 结构与 Base64 VLQ 编码，作者逐步展示了浏览器如何通过这些映射信息，将压缩后的生产代码还原回开发者可读的源文件位置。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 引言：Source Map 的作用
• 解释 Source Map 如何连接构建后的 “生产代码” 与原始源文件
• 举例说明浏览器在 DevTools 中如何利用 Source Map 还原源码位置

2. TypeScript 构建管线（Build Pipeline）
• 概述现代 JavaScript 构建的三个阶段：转译 (Transpilation)、打包 (Bundling)、压缩 (Minification)
• 展示原始 TypeScript 源文件示例（add.ts / fibonacci.ts / main.ts）
• 强调每个阶段 Source Map 保持了源代码映射关系

3. Source Map 文件结构
• Source Map 为 JSON 格式，通常以 .js.map 结尾
• 字段详解：
• version：版本号（通常为 3）
• file：对应的生成后文件名
• sourceRoot：源文件路径前缀
• sources / sourcesContent：原始文件路径和内容
• names：标识符数组（变量与函数名）
• mappings：压缩映射字符串（核心内容）
• 指出 mappings 字段使用 VLQ 编码进行空间压缩

4. 理解映射机制：VLQ 编码 (Variable Length Quantity)
• mappings 字符串由逗号与分号组成，分号分行、逗号分列表示段（segment）
• 三种 segment 格式：
• 单值：仅表示生成列位置
• 四值：完整的源映射
• 五值：包含原始名称索引（变量或函数重命名时使用）
• 说明相对位置编码（delta encoding）原理——通过存储偏移量而非绝对位置实现高压缩率

5. VLQ 编码的工作原理
• 每个数字通过以下步骤编码为 Base64：
1. 编码符号位（sign bit）区分正负数
2. 拆分成 5 位数据块+1 位延续标志 (continuation bit)
3. 使用 Base64 字符表映射（A–Z, a–z, 0–9, +, /）
• 举例说明数字 7 如何被编码为 “O”
• 总结其节省空间与高效解析的优点

6. 实例解读与调试意义
• 通过 add.js.map 的 decode 过程展示行列映射
• 演示如何由压缩代码精确反查到原始 TS 源文件行列
• 强调 Source Map 在前端调试、错误定位和代码回溯中的核心地位

author Manoj Vivek

Do more with less. | Polar Signals

The Inner Workings of JavaScript Source Maps

A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.

#优质博文 #开发流程 #Git #工程化 #开源
其实是之前的看到的文章里看到的，觉得有用，Mark 一下。
The stacking workflow

AI 摘要：本文介绍了一种名为 “Stacking” 的开发工作流，用于优化传统的 Git 分支与代码评审流程。它通过将大型改动拆分为多个相互依赖的、小而独立的 PR，实现并行开发与评审，显著减少等待时间与合并冲突。文章还提及多种自动化工具，可帮助开发者轻松管理 Stacked PRs，从而在团队协作中显著提高代码质量与生产效率。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 开发与评审的痛点
• 传统代码评审流程耗时长，对开发者与评审者都是负担。
• 分布式团队受时区影响，沟通与迭代周期延长。
• 在等待评审期间，作者被迫停滞，影响特性迭代与开发效率。

2. 为什么需要 Stacking
• Stacking 将开发和评审流程并行化，可在上一个 PR 尚未合并前继续开发下一步工作。
• 通过拆分大型改动为多个小型、依赖性的 PR，减少复杂度，使每次评审更聚焦。
• 改动间的依赖关系清晰，能更安全地选择性合并各 PR，保持项目演进的灵活性。

3. 手动 Stacking 的困难
• 每个分支都需递归 rebase（再基化），遇上上游改动时需层层同步，极为繁琐。
• Git 原生命令行（CLI）对该流程支持有限，手动处理冲突成本高，容易出错。

4. 支持 Stacking 的工具生态
• GitHub 集成方案：具有 CLI、VS Code 插件与 Web UI，可同步管理栈式 PR。
• 开源 CLI 工具：如 ghstack、git-branchless 等，提供抽象化的 stack 操作流程。
• Meta 的新版本控制系统含原生 Stacking 支持。
• Git 新选项 --update-refs 为 stacking 流程带来更多便利。

5. 采用 Stacking 的价值
• 推动开发者以更模块化的思维进行编码，提升代码可读性与长期可维护性。
• 有助于团队快速理解、学习或回滚更改。
• 不论语言、架构、仓库结构（polyrepo/monorepo），Stacking 均可适用。
• 一旦熟悉该模式，多数开发者会主动维护 5–10 个 PR 栈，形成高效的持续开发节奏。

www.stacking.dev

The stacking workflow

Stacked PRs. Stacked diffs. Stacked changes. A better workflow to manage pull requests.

#优质博文 #前端 #AI #MCP #工程化 #nextjs
Next.js DevTools MCP: Your Development Server Just Got Smarter

AI 摘要：本文介绍了由 Vercel 提供的 next-devtools-mcp 套件，它利用 Next.js 16+ 的内置 MCP (Model Context Protocol) 端点 /_next/mcp，让 AI 编码助手（如 Claude、Cursor、Gemini 等）直接访问开发服务器的实时运行数据，包括构建错误、运行错误、TypeScript 类型检查、页面路由、Server Action 定义、日志与配置，从而显著提升调试与代码生成的智能化水平。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. Next.js 16+ 的内置 MCP 支持
• 自 Next.js 16 起，框架内置 /_next/mcp 端点，可暴露实时的项目状态信息。
• 该端点支持 next-devtools-mcp 包进行自动发现与对接，无需额外配置。

2. 安装与集成方式
• 针对不同 AI 编辑器（Claude Code、OpenAI Codex、Google Gemini）提供简易的 npx 安装命令。
• 其他编辑器可通过在项目根目录添加 .mcp.json 文件实现集成。
• 重启开发服务器后，next-devtools-mcp 自动发现并连接 MCP 端点。

3. 实时错误访问与改进
• 在传统环境中，开发者只能复制错误日志手动传给 AI；
• 使用 MCP 后，Claude 等助手能自动获取错误堆栈、类型及关联代码文件；
• AI 可即时分析、修复并验证结果，大幅减少人工往返操作。

4. 内置工具与功能说明
• get_page_metadata：返回路由、组件与页面结构信息。
• get_project_metadata：暴露项目配置与依赖。
• get_server_action_by_id：查询特定 Server Action 定义。
• get_logs：访问开发服务器日志。
• nextjs_docs：查询官方文档并提供版本相关代码参考。
• upgrade_nextjs_16：运行 Next.js 16 升级代码改造。
• enable_cache_components：配置缓存组件并执行预检。
• browser_eval：通过 Playwright 集成运行浏览器测试。

5. 版本兼容与限制
• Next.js 16+ 获得完整支持，包括实时错误、状态与日志访问。
• Next.js 15 及更低版本仅支持部分功能，如升级脚本与文档查询。

author Trevor Lasn

trevorlasn.com

Next.js DevTools MCP: Your Development Server Just Got Sm...

The Next.js DevTools MCP connects Claude and Cursor to your running dev server. I use it every day.

#优质博文 #测试 #前端 #工程化 #新动态
Announcing Vitest 4.0：Vitest 团队宣布推出 Vitest 4.0，这是该测试框架的重大版本更新。此次版本将 Browser Mode 标记为稳定，让开发者能在真实浏览器环境中运行单元测试，从而获得更高的可靠性。此外还引入了 视觉回归测试 与 Playwright Trace 支持，提升了调试与测试体验。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. 发布概况
• Vitest 在过去一年内从每周 700 万下载增长至 1700 万，社区影响力显著提升。
• 经过近一年的开发，Vitest 4.0 正式发布。
• 该版本包含若干重大变更（breaking changes），需参考迁移指南进行升级适配。

2. Browser Mode 稳定
• Browser Mode 结束 Beta 阶段，正式进入稳定版。
• 支持在真实浏览器中运行组件测试，不再局限于 JSDOM 等模拟环境。
• 使用相同的 Vitest API，无需修改测试代码。
• 基于 Playwright 等 provider 实现执行环境，但不替代现有 E2E 工具，仅改变测试运行方式。

3. 新增功能与改进
• 视觉回归测试 (Visual Regression Test)：在 Browser Mode 下进行组件截图与参考图对比，用于检测视觉变化。
• Playwright Traces：生成可在 Trace Viewer 中分析的跟踪文件，辅助调试。
• 报告系统 (reporter) 更新、类型感知钩子 (type-aware hooks) 等多项改进。

4. 版本变更与迁移
• 此次为主版本升级，包含不兼容改动。
• 官方提供迁移指南：Migration guide。

5. 未来计划与社区
• 团队将重点优化性能和 Browser Mode 体验。
• 报告问题可通过 GitHub Issues 提交。

void(0)

Announcing Vitest 4.0

Vitest 4.0 is released with Browser Mode being marked stable, Visual Regression testing support, and Playwright Trace support. The Vitest team will focus on performance improvement in the upcoming quarter. This major release includes breaking changes.

#优质博文 #React #前端 #工程化
React Folder Structure in 5 Steps (2025)

AI 摘要：本文详解了作者多年实践总结出的 React 项目结构化思路，以「逐层演进」为主线，从单文件组件到分页驱动(Page-driven)架构，展示了如何通过结构分层与命名规范，实现 React 应用在复杂度与团队协作下的平衡。文章强调不存在唯一正确方案，读者应根据项目规模与团队习惯灵活调整。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 单文件阶段（Single React File）
• 初始项目通常包含一个 src/App.js 文件。
• 所有组件起初可写在单文件中，便于快速原型开发。
• 随项目增长，应将可复用组件拆分，以减少冗余和嵌套复杂度。

2. 多文件阶段（Multiple React Files）
• 抽离可重复使用的组件为独立文件，如 List 和 ListItem。
• 通过文件导出（export）定义组件的“公共接口”(API)。
• 使用文件扩展名策略（.js/.jsx/.ts/.tsx）统一文件规范。
• 建议仅对可复用组件拆分，不要过早抽象。

3. 文件夹化阶段（From Files to Folders）
• 随组件复杂度增加，将相关技术关注点（测试 test、样式 style、类型 type、工具 utils）集中在组件文件夹。
• 采用“一个组件一个文件夹”的结构，如 src/list/ 或 src/app/。
• 使用 index.js 作为模块对外出口（即“barrel 文件”），控制组件的公共 API。
• 讨论命名规范（如 .spec.js、.module.css）与层级深度（避免超过两级嵌套）。
• 建议尽量避免过深目录，用功能聚合代替结构嵌套。

4. 技术型文件夹（Technical Folders in React）
• 当项目达到中等规模，应区分“组件类”与“技术类”逻辑。
• 在 src/ 中增设按技术职能划分的文件夹：
• components/：组件逻辑
• hooks/：自定义 React Hooks
• context/：应用全局状态
• services/：通用服务（格式化、错误追踪、请求封装等）
• 服务示例通过 Intl API 实现日期格式化并由模块封装暴露。
• 推荐使用路径别名（alias，如 @/services/...）避免相对路径混乱。
• 指出 barrel 文件的利弊——简化导入但可能削弱 tree-shaking。

5. 功能型文件夹（Feature Folders in React）
• 大型项目中，按“业务领域（Feature）”划分文件夹，以聚合其内所有组件与逻辑。
• 结构区分：
• feature/：业务特定代码（如 user、post、payment）
• components/：跨 feature 可复用的 UI 组件
• services/hooks/context：依旧保留为全局可重用逻辑
• 每个 feature 内可包含对应 components/、services/ 等子文件夹以划分技术关注点。
• 帮助团队并行开发、限域依赖，提高可维护性与灵活性。

6. 页面驱动结构（Page Driven Structure）
• 当应用存在多页面（特别是 Next.js 或 Vite + React），建议围绕 pages/ 或 app/ 文件夹组织。
• 每个页面对应入口点 (page.tsx)，并链接相关 feature。
• 在同页面内是否嵌套 feature/取决于其复用度与作用域；鼓励保持一致的目录结构。
• 比较 Next.js 的文件路由与客户端路由在结构设计上的差异。
• 最终形成具有多层抽象但一致规则的工程化结构，支持扩展与团队协作。

7. 总结与启发
• 无绝对正确的文件结构，应随项目自然演化。
• 遵循“按复用程度而分层”，“按技术职能而归类”，“按业务边界而划分”的原则。
• 五步推进法可帮助开发者在项目复杂化时保持组织清晰。

author Robin Wieruch

www.robinwieruch.de

React Folder Structure in 5 Steps [2025]

React Folder Structure in 2025 for large React projects. The guide walks you through a file structure from small to large project ...

#优质博文 #vite #工程化 #前端 #开源 #新动态
VueConf 上说的 Vite+，介绍文章也来了（
Announcing Vite+

AI 摘要：Vite+ 是在 ViteConf 上发布的全新统一工具链（unified toolchain），旨在整合构建、测试、格式化、代码规范检查和库打包等开发环节，解决 JavaScript 工具碎片化与性能瓶颈问题。它在 Vite 基础上新增 vite new、vite test、vite lint、vite fmt、vite lib、vite run、vite ui 等命令，并基于 Rust 实现完整编译链以实现极致性能。Vite+ 将采用 “source-available” 的商业许可策略，对个人及开源用户免费，对企业采取付费订阅模型，目标是构建可持续的前端生态。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. Vite+ 简介
• 来源于 Vite，同样可从 npm 安装；作为简体升级版，整合更多开发命令。
• 目标是提供统一的前端工程体验，使复杂项目的开发、测试与构建更加高效。
• 与 React、Vue、SvelteKit 等框架无缝兼容，并可直接用于单体或 monorepo。

2. 核心特性与命令集
• vite new：生成新项目或为 monorepo 生成代码模块。
• vite test：由 Vitest 驱动，兼容 Jest API，支持浏览器测试、分片和可视化回归测试。
• vite lint：集成 Oxlint，支持类型感知检查，性能比 ESLint 快百倍。
• vite fmt：即将发布的 Oxfmt 格式化工具，兼容 Prettier，提供更多换行与格式控制能力。
• vite lib：用于构建库，集成 tsdown 与 Rolldown，自动生成类型声明。
• vite run：智能缓存的任务执行器，无需显式配置即可获得细粒度缓存。
• vite ui：图形化开发工具，展示模块解析、打包与摇树分析等信息。

3. Rust 驱动的底层实现与性能优化
• 全链路由 Rust 重构实现，包括 parser、resolver、transformer、minifier、bundler。
• 高度性能调优，并被 Framer、Linear、Atlassian、Shopify 等公司采用。
• 暴露 parse 和 transform API，便于二次开发。

4. 解决的问题：JavaScript 工具生态的碎片化
• 多项目多团队导致依赖不一致、安全审核复杂与工具迁移成本高。
• Vite+ 旨在提供统一、协同的工具基础架构，减少配置、调试与迁移成本。
• 通过一致的命令与生态整合，提升开发协作效率。

5. 商业化与开源策略
• 将采用 “source-available” 策略：个人、开源、小型团队免费使用；企业需订阅授权。
• 收费部分将反哺 Vite+ 及其基础开源项目（Vite、Vitest、Rolldown、Oxc）。
• 承诺上述基础项目始终保持 MIT 开源许可。
• 目标是在维持社区信任与生态创新的前提下，探索开源项目的可持续商业模式。

6. 计划与参与方式
• 预计 2026 年推出公开预览版。
• 招募早期试用用户，可访问 viteplus.dev 参与测试。
• 官方希望社区共同塑造 Vite+ 的发展方向。

author Evan You

void(0)

Announcing Vite+

Introducing Vite+, a unified toolchain for JavaScript.

#优质博文 #后端 #工程化 #架构
Stop writing REST APIs from scratch in 2025 - LogRocket Blog

AI 摘要：本文指出传统手动编写 REST API 的方式存在重复、易错和效率低等问题，建议开发者在 2025 年采用基于 schema 的声明式 (declarative) API 架构。文章通过对比 Express + yup 的旧式流程与 tRPC + Zod 等现代框架的 schema 驱动方案，展示了后者在类型安全、自动文档生成和开发效率上的明显优势。文末总结，这一趋势代表了 API 开发范式的转变：不再从零搭建 REST，而是借助框架实现「单一事实源 (Single Source of Truth)」的自动化、类型安全和可维护性。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 传统 REST API 的问题
• 以 Express + yup 为例，展示编写一个 POST /users 接口的流程需要多次定义相同结构（TypeScript 接口与验证 schema），违反 DRY 原则。
• 手动设置中间件、类型转换、错误捕获、更新文档等步骤繁琐且易出错。
• 代码重复导致类型不同步、文档过时等潜在风险。

2. 基于 schema 的声明式解决方案
• 引入 tRPC + Zod：仅需定义一次 schema，即可自动推导类型、内建验证、生成文档。
• 省去中间件与显式类型转换，错误由框架统一处理。
• 实现「一份定义，三方同步」：类型、安全与文档共用同一 schema。

3. 行业框架的趋势与示例
• Hono：以标准 Web API 语法结合 zValidator 内置验证，简化 Express 式编写。
• Fastify：通过 schema 改进性能，将类型安全转化为运行时效率，并生成 JSON Schema。
• NestJS：通过装饰器 (decorator) 方式实现 declarative 验证与类型推断，无需手动配置。

4. 对比与优势总结
• 开发速度：传统方案冗长且易同步出错，schema 驱动模式定义一次即可。
• 安全性与可靠性：旧式依靠手动转换，schema 模式实现端到端类型安全。
• 文档维护：旧方式需手写 OpenAPI，schema 模式可自动生成实时文档。

5. 结论与未来趋势
• 手工编写 REST API 已成为反模式，schema 驱动的 declarative 模型是未来标准。
• 关键价值在于「写更好的代码」，而非「写更少的代码」。
• 单一 schema 即为验证层、类型系统与文档源，使开发更快、更安全、更可维护。

author Ikeh Akinyemi

LogRocket Blog

Stop writing REST APIs from scratch in 2025 - LogRocket Blog

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.

#优质博文 #React #性能优化 #前端 #工程化 #新动态
React Compiler 1.0 来辣！（虽然是 10.7 的消息但是我真的很忙才看到）
不过想尝鲜的应该早用上了（）
React Compiler v1.0 – React

AI 摘要：React 团队发布 React Compiler 1.0，这是一个稳定且可在生产环境中使用的构建时优化工具。它可自动分析 React 组件与 hooks 的数据流与可变性，实现自动记忆化，从而减少渲染次数并提升性能。该编译器适用于 React 与 React Native，与 Babel、Vite、Next.js、Expo 等生态紧密集成，并提供增量迁移指南和内置 lint 规则以强化 “Rules of React”。此次发布标志着历时近十年的工程成果落地，开启 React 新的性能优化时代。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 背景与发布概况
• React Compiler 1.0 正式发布，可在 React 与 React Native 中使用。
• 支持与 Expo、Vite、Next.js 等集成，默认在新项目中启用。
• 历经十年研发，从 Prepack 到 HIR（高阶中间表示 High-Level Intermediate Representation）的多次重构。

2. 编译器原理与功能
• React Compiler 作为构建时优化工具，在 Babel 插件阶段分析 AST（抽象语法树 Abstract Syntax Tree）。
• 通过自动记忆化优化组件与 hooks，可在条件渲染后仍实现 memoization。
• 拥有验证与诊断机制，通过数据流分析发现潜在违反 Rules of React 的代码。
• 与 eslint-plugin-react-hooks 集成，为开发者提供静态规则检测支持。

3. 安装与使用方式
• 支持 npm、pnpm、yarn 等安装方式：babel-plugin-react-compiler@latest。
• 改进了依赖分析算法，支持可选链与数组索引依赖。
• 提供 Playground 与文档供开发者测试优化效果。

4. 性能表现与生产验证
• 已在 Meta Quest Store 等大型应用投入使用。
• 实测初始加载与页面切换性能提升 12%，部分交互速度提升 2.5 倍。
• 性能提升同时保持内存中性，证明优化可靠。

5. 兼容性与 Lint 集成
• 兼容 React 17+，React 19 可直接启用编译器特性。
• ESLint 规则合并入 eslint-plugin-react-hooks@latest，替代独立插件。
• 强化了 setState、ref 等模式检测，防止渲染循环和 unsafe 渲染行为。

6. 与 useMemo / useCallback 的关系
• 默认由编译器自动进行 memoization，大多数情况下无需手动使用 useMemo/useCallback。
• 对需要精准控制依赖的场景仍建议保留或使用手动记忆化。

7. 新项目与渐进式迁移方案
• Expo SDK 54+ 默认启用编译器，Vite 与 Next.js 模板可直接启用。
• 提供渐进迁移指南，帮助旧项目分阶段集成 React Compiler。

8. swc 与构建工具支持
• 支持 Babel、Vite、Rsbuild 等构建工具，swc 插件仍在实验阶段。
• Next.js 15.3.1+ 可显著提升构建性能，Vite 通过 vite-plugin-react 启用编译器。
• 正在与 oxc 团队合作，为未来 rolldown 支持做准备。

9. 升级与版本管理建议
• 未来版本可能改变 memoization 策略，需保持端到端测试。
• 建议固定编译器版本（--save-exact）以避免意外行为变化。
• 强调遵守 Rules of React 以确保编译器优化安全有效。

author Lauren Tan, Joe Savona, Mofei Zhang

react.dev

React Compiler v1.0 – React

The library for web and native user interfaces

#优质博文 #前端 #工程化
Birth of Prettier

AI 摘要：本文由 Prettier 作者 Vjeux 亲述该工具从萌芽到成为 JavaScript 世界事实标准的全过程。他回顾了从学生时代对代码格式要求的启蒙，到在 Facebook 亲历代码风格冲突，并探索各种格式化方案（如 gofmt、dartfmt）失败的原因；最终，他与合作者 James Long 等人推动 Prettier 诞生。文中详述了算法思想（基于 Philip Wadler 的 A prettier printer）、工程推进与开源协作、在 Meta 的落地推广、以及如何彻底终结开发者的格式化争论。最后反思了开源维护的经济困境与对未来开发者工具的展望。

author vjeux

#优质博文 #React #工程化 #前端
好东西啊。
NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect

AI 摘要：这是一个 ESLint 插件，用来帮助开发者发现并避免在 React 项目中错误或不必要使用 useEffect 的场景。通过提供多条规则，它能让代码逻辑更清晰、性能更高、Bug 更少，尤其对初学者有帮助，同时对有经验的开发者也可能带来新的启发。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 插件介绍与背景
• 核心思想是减少不必要的 React useEffect 使用
• 改善代码可读性，提高性能，减少逻辑错误
• 推荐新手使用，同时对老手也有价值

2. 安装与配置
• 提供 npm 和 yarn 的安装方法
• 支持 .eslintrc 旧版配置与 eslint.config.js 新版配置
• 可与 eslint-plugin-react-hooks 一起使用以获得更精准的依赖分析

3. 核心规则（Rules）
• no-derived-state：禁止在 effect 中存储衍生 state
• no-chain-state-updates：禁止在 effect 中链式更新 state
• no-event-handler：禁止用 effect 来做事件处理逻辑
• no-adjust-state-on-prop-change：禁止在 prop 改变时用 effect 调整 state
• no-reset-all-state-on-prop-change：禁止在 prop 改变时通过 effect 重置所有 state
• no-pass-live-state-to-parent & no-pass-data-to-parent：禁止在 effect 中向父组件传递 state 或数据
• no-initialize-state：禁止在 effect 中初始化 state
• no-manage-parent：禁止纯依赖 props 的 effect
• no-empty-effect：禁止空的 effect 定义
• 默认推荐配置会启用全部规则作为 warning

4. 测试与实践
• 项目中包含 (in)valid 例子用于规则验证
• 强调插件并非覆盖所有情况，但尽量减少误报

5. 社区与反馈
• 鼓励开发者提出问题和改进建议
• 插件以减少 false positives（误报）为设计目标，即时存在偶发的漏报 (false negatives)

6. 学习资源
• React useEffect 官方文档
• You Might Not Need an Effect
• Synchronizing with Effects
• Separating Events from Effects
• Lifecycle of Reactive Effects

GitHub

GitHub - NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect: Catch unnecessary React useEffect hooks to make your code…

Catch unnecessary React useEffect hooks to make your code simpler, faster, and safer. - NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect

#优质博文 #前端 #依赖管理 #React #工程化
当然是选择 node-modules-inspector 啦！
How to keep package.json under control

AI 摘要：本文结合 Val Town 的实际开发经验，探讨了在复杂 React 应用中如何避免依赖臃肿、保证 package.json 的可控性。作者强调理解依赖、避免不必要引入、分析依赖大小、借助工具管理更新与清理，并推荐学习优秀开发者的模块。核心观点是：依赖管理是前端开发的必修课，需在技术现实和理想简洁之间找到平衡。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 理解依赖与选择
• 在引入新依赖时应阅读源码和 README，而不是盲目安装
• 小型依赖可直接 vendor（复制进项目）而非整个 npm 安装
• 需要权衡依赖体积与使用场景，避免冗余引入

2. 工具与方法论
• 使用 npm ls、package-lock.json、pnpm why 等追踪依赖树与冗余
• 分析依赖的实际体积（开发环境 node_modules 和生产构建大小双维度）
• 借助 rollup-plugin-visualizer、Next.js bundle analyzer 等工具可视化构建产物

3. 模块评估标准
• 好的模块：有维护历史、TypeScript 类型支持、完整测试、文档清晰
• 坏的模块：不符合实际问题、缺乏维护或质量低劣
• 重点在于理解问题本身与模块实现的契合度

4. 清理与升级
• 借助 Renovate 持续更新依赖，避免积压
• 借助 Knip 清理未使用的依赖和文件，保持项目整洁
• 渐进式更新比“年度大升级”风险更低

5. 社群与开发者生态
• 推荐关注优秀开发者如 Sindre Sorhus、isaacs、Matteo Collina、Mafintosh、wooorm、unjs、Rich Harris 等
• 持续追踪他们的作品，有助于找到高质量依赖

6. 哲学与实践
• 依赖不可避免，是现代 Web 开发的本质
• 需要在“必要复杂性”与“依赖治理”之间找到平衡
• 依赖管理是一种长期的“gardening”（园艺）工作

author Tom MacWright

GitHub

GitHub - antfu/node-modules-inspector: Interactive UI for local node modules inspection

Interactive UI for local node modules inspection. Contribute to antfu/node-modules-inspector development by creating an account on GitHub.

#优质博文 #bundler #工程化 #前端
Bundler Tree Shaking 原理及差异 · web-infra-dev · Discussion #28

AI 摘要：Tree shaking（摇树优化）已成为现代前端打包（bundler）领域的重要优化手段。不同 bundler 工具（如 Webpack、Rollup、esbuild、Turbopack）由于应用场景和关注点不同，实现 tree shaking 的原理与细节也有所差异。文章系统对比了这些工具的 tree shaking 实现，包括分析粒度、副作用（side effects）判定、模块/语句/AST（抽象语法树）层面的优化，以及各自的优势与局限性，并详细剖析了典型案例。对于需要深入理解前端 build 工具原理与优化策略的开发者极具参考价值。

author web-infra-dev ahabhgk

GitHub

Bundler Tree Shaking 原理及差异 · web-infra-dev · Discussion #28

English version Tree shaking 在如今的前端打包领域已成为极为重要且不可或缺的一部分。鉴于各个 bundler 的适用场景和侧重点存在差异，因此各个 bundler 之间的 tree shaking 实现方式也各不相同。例如，Webpack 主要用于前端应用打包，侧重于正确性，其 tree shaking 主要关注跨模块级别的优化；而 Rollup 主要用于库打包，...

#优质博文 #CSS #TypeScript #前端 #类型安全 #工程化
The Multi-Repository TypeScript Problem

AI 摘要：本文深入探讨了在大型 TypeScript 项目、尤其是多团队、多仓库（polyrepo）架构下，如何在服务边界之间实现类型安全。作者通过剖析现有单仓库（monorepo）与多仓库在类型共享上的差异，提出了一套自动化提取、打包、共享和验证 TypeScript 类型定义的新思路，从而实现跨服务间类型兼容性检测，最大限度利用 TypeScript 本身的类型系统能力，实现 monorepo 式的类型安全体验。

1. TypeScript 项目架构对类型共享的影响
• 对比单仓库（monorepo）与多仓库（polyrepo）架构下服务间类型共享的简易性和复杂性
• 强调 monorepo 在类型共享上的先天优势，但多仓库在业务组织上的必要性

2. 跨仓库类型校验的实际挑战
• TypeScript 类型检查器需要获取完整工程上下文，但多仓库使类型定义分散
• 讨论依赖和类型递归拉取带来的复杂性，不同仓库可能存在同名、类似或依赖链深度不一的类型

3. 类型提取、打包和自动化流程
• 利用 ts-morph、SWC 等工具自动化精准地提取、分发类型定义
• 提出基于接口路由自动生成类型别名，解决多团队协作下类型命名不一致问题
• 持续集成（CI）流水线以独立项目方式聚合、校验和比对类型包，提高自动化校验覆盖面和准确率

4. 类型兼容与校验自动化策略
• 利用 TypeScript 类型赋值（assignability）规则进行自动验真，无需自定义冗余逻辑
• 构建临时 TypeScript 项目，自动加载各仓库导出的类型包，通过编译器 API 比对并提取错误
• 充分借力 TypeScript 编译器本身能力，让生态演进自然受益

5. 工程实践与系统扩展性
• 跨仓库类型校验架构具备良好的可扩展性和维护性
• 所有工程增强无需魔改 TypeScript，可高效适配未来升级

author Carrick

www.carrick.tools

The Multi-Repository TypeScript Problem

Navigating Type Safety Across Service Boundaries

cosine - 前端人の日常频道

#碎碎念 #前端 #工程化 好好好 “cargo for JavaScript” 好大的饼，等发布了康康，我对这种还是一向持积极态度的，有人弄是好事

看到有没到现场的群友觉得vite继续做这些也无法避免继续让前端工具链碎片化。

但其实现场直接有人问尤雨溪这个经典问题了，前面10个工具链不够好，又开发一个，于是我们有11个了，怎么面对这种问题？
回答是需要时间，实现再好也不会有魔法让所有想切换的人一下子换成vite+工具链；
演讲前文也提到过，在合适的时机做合适的事很重要，vite实际上从起步发展到现在，进展非常迅速，社区接受度已经很高了（已经被广泛采用或者作为大部分框架的默认脚手架），是前端工具链最有希望做成这件事的团队。

如果问我，我会说看看其他领域怎么解决类似问题的，cargo的优秀示范在前面，py那边也要uv在做类似的生态位，前端工具链当然也需要这样一个角色

#优质帖子 #前端 #Node #工程化 #可扩展性 #DDD #模块化 #Nest
Best Scalable File Structure for unopinionated Node frameworks?

AI 摘要：本文讨论了在无特定意见的 Node.js 框架（如 Express、Hono 等）中，如何设计一个可扩展且适合生产环境的文件结构。作者和评论者围绕领域驱动设计（DDD）、模块化单体架构（Modular Monolith）以及文件结构对代码库可维护性的影响展开了激烈讨论。部分人认为文件结构对团队协作和代码库扩展至关重要，而另一些人则认为其重要性被夸大，强调不应过于纠结于目录布局。

Reddit

From the node community on Reddit: Best Scalable File Structure for unopinionated Node frameworks?

Explore this post and more from the node community