#优质博文 #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

#优质博文 #前端 #node #工程化
Modern Node.js Patterns for 2025

AI 摘要：本文深入探讨了 Node.js 在 2025 年的现代开发模式，展示了其从早期的回调和 CommonJS 主导到如今基于标准的开发体验的巨大转变。文章重点介绍了 ES 模块（ESM）、内置 Web API、测试工具、异步模式、流处理、Worker 线程、安全性与性能监控等现代特性，旨在帮助开发者构建更高效、可维护且符合 Web 标准的应用程序。通过减少外部依赖、提升开发者体验和优化部署方式，Node.js 已成为一个全面的开发平台，为未来的服务器端 JavaScript 开发奠定了坚实基础。

1. 模块系统：ESM 成为新标准
• 对比 CommonJS 和 ES 模块，ESM 提供更好的工具支持和 Web 标准一致性。
• 介绍 node: 前缀用于内置模块导入，避免命名冲突并明确依赖。
• 强调顶层 await 特性，简化初始化代码，消除 IIFE（立即执行异步函数）模式。

2. 内置 Web API：减少外部依赖
• 原生 Fetch API 取代外部 HTTP 库（如 axios），支持超时和取消操作。
• AbortController 提供标准化操作取消机制，适用于多种异步操作。

3. 内置测试工具：无需外部框架
• Node.js 内置测试运行器，提供现代化 API，支持单元测试、异步测试和覆盖率报告。
• 开发中的 watch 模式提供即时反馈，简化测试流程。

4. 高级异步模式：成熟的异步处理
• 结合 async/await 与并行执行（如 Promise.all ）和结构化错误处理，提升代码性能和可读性。
• 使用 AsyncIterators 改进事件驱动编程，支持流式事件处理和背压控制。

5. 流处理与 Web 标准集成
• 现代流处理 API（如 pipeline ）提供自动清理和错误处理，简化操作。
• 支持 Web Streams，实现与浏览器代码和边缘环境的无缝兼容。

6. Worker 线程：CPU 密集型任务的并行处理
• Worker 线程实现多核利用，适用于计算密集型任务，避免阻塞主线程。
• 示例展示如何将繁重计算任务委托给 Worker 线程，保持应用响应性。

7. 提升开发者体验：内置工具简化开发
• 内置 watch 模式和环境文件支持，替代 nodemon 和 dotenv ，减少配置负担。
• 简化开发流程，提升开发效率。

8. 现代安全与性能监控
• 实验性权限模型限制应用访问权限，遵循最小权限原则。
• 内置性能监控工具（ perf_hooks ）帮助识别瓶颈，无需外部 APM 工具。

9. 应用分发与部署优化
• 支持单文件可执行应用，简化 CLI 工具和桌面应用的部署，无需用户安装 Node.js。

10. 现代错误处理与诊断
• 结构化错误处理提供丰富的上下文信息，便于调试和监控。
• 高级诊断工具（如 diagnostics_channel ）帮助深入了解应用内部行为。

11. 现代包管理和模块解析
• 支持导入映射（Import Maps），简化内部模块引用，便于重构。
• 动态导入支持按需加载和代码分割，适应不同环境需求。

总结与未来展望
• 强调拥抱 Web 标准、使用内置工具、优化异步模式和开发者体验的重要性。
• Node.js 保持向后兼容，支持渐进式采纳现代模式，确保应用长期可维护性。

author Ashwin

#优质博文 #前端 #工程化 #javascript #新动态
🤖 JavaScript Weekly #742

AI 摘要： 本期 JavaScript Weekly 聚焦于 JavaScript 生态系统的最新动态，包括 ECMAScript 2025 规范的正式批准、Vite 7.0 的发布以及多个前沿工具和框架的更新。文章涵盖了 JavaScript 未来发展的提案、AI 工具在开发中的应用、以及多种实用库和工具的最新版本信息。此外，还介绍了多个技术文章和视频教程，帮助开发者提升技能和了解行业趋势。

1. Ecmascript 2025：有什么新功能？：Ecma 国际大会正式批准了 ES2025 语言规范，Dr. Axel Rauschmayer 提供了简洁的解读，方便开发者快速了解新特性。
2. JavaScript 未来发展提案：Deno 团队整理了 TC39 进程中正在推进的 9 个提案，并附上代码示例，展示了 JavaScript 未来的发展方向。
3. V8 团队的深度解析文章更新 - V8 中引入的两个新优化，旨在加速 WebAssembly。 #wasm
4. 版本更新：Transformers.js 3.6、zx 8.6、Node.js 多个版本更新、Prettier 3.6、Bun v1.2.17 和 SVGO 4.0 的发布信息。
5. Angular 团队创建了一套 LLM 提示和 AI IDE 规则文件，以帮助 Angular 开发者从 LLM 中获得更好的代码
6. 在复杂视觉应用程序中实现 Undo/Redo 系统
7. 没时间学习（Web）框架 X —— 你如何判断学习新事物是否值得花时间？
8. 在编写 WASM 组件时比较 Rust、JavaScript 和 Go
9. 如何撰写引人入胜的软件发布公告
10. 介绍了 Hono 4.8 跨运行时框架、LogTape 1.0.0 通用日志工具、Google 的 Gemini CLI AI 代理工具、PLJS 1.0 Postgres 插件、Marked 16.0 Markdown 解析器、Vue Infinity 数据虚拟化渲染工具、Spark Three.js 3D 渲染器以及多个图表库和框架的更新。

2Ality

Ecma International approves ECMAScript 2025: What’s new?

On 25 June 2025, the 129th Ecma General Assembly approved the ECMAScript 2025 language specification (press release, GitHub release), which means that it’s officially a standard now. This blog post explains what’s new.

#优质博文 #前端 #css #工程化
挺好的探讨 CSS 特异性的文章，适合初学者概览。
CSS Cascade Layers Vs. BEM Vs. Utility Classes: Specificity Control — Smashing Magazine

AI 摘要：本文由 Victor Ayomipo 撰写，深入探讨了 CSS 中特异性（specificity）控制的复杂性及其解决方案。文章详细分析了三种主要的 CSS 特异性管理策略：BEM（Block-Element-Modifier）、Utility Classes（实用类）和 CSS Cascade Layers（层叠层）。通过对比它们的优缺点、使用场景及特异性控制方式，作者旨在帮助开发者理解并选择适合项目需求的 CSS 组织方式，同时强调保持低特异性的重要性，避免使用 !important 等不良实践。

1. 引言：CSS 特异性的挑战
• 介绍了 CSS 特异性导致的样式应用问题，如样式覆盖失败的常见困扰。
• 强调理解特异性比依赖 !important 更可持续，提出特异性问题是 CSS 开发中的核心挑战之一。

2. 特异性基础（Specificity 101）
• 解释了特异性如何通过浏览器层叠算法决定样式优先级。
• 通过示例（如 .cart-button 和 .cart-button.sidebar）展示了项目扩展中特异性冲突的加剧。
• 概述了三种策略（BEM、Utility Classes、Cascade Layers）在控制特异性上的不同思路。

3. 作者与特异性的关系
• 分享了作者对特异性理解的演变，从基础规则到深入研究 CSS 层叠机制。
• 通过实际代码案例，展示了特异性冲突（如旧代码与新样式的优先级问题）及解决时的困境。
• 提出个人原则：保持低特异性，避免复杂选择器链，必要时重构代码。

4. BEM：经典系统
• 详细介绍了 BEM 的命名方法论（Block、Element、Modifier），强调其通过显式层级降低特异性。
• 优点：代码可预测，组件隔离，特异性低且一致。
• 缺点：类名冗长，复用性受限，命名困难，需灵活应用（如结合全局类）。

5. Utility Classes：通过回避特异性
• 描述了 Utility Classes（原子化 CSS）的理念，即通过单一功能的类保持最低特异性（如 p-2、text-red）。
• 优点：快速开发，可预测性高，覆盖简单。
• 缺点：代码可读性差，HTML 冗长，品牌色调整等全局变更困难，父子关系处理受限。

6. Cascade Layers：设计上的特异性控制
• 介绍了 CSS Cascade Layers 的强大功能，通过 @layer 定义样式优先级，超越传统特异性规则。
• 优点：提供绝对控制力，可覆盖高特异性选择器（如 ID 选择器）而无需 !important。
• 缺点：特异性仍起作用，!important 行为特殊，易被滥用导致层级复杂。

7. 三者对比
• 通过表格形式对比了 BEM、Utility Classes 和 Cascade Layers 在特异性控制、代码可读性、组织方式等多个维度的表现。
• 最佳场景：BEM 适合设计系统，Utility Classes 适合快速构建，Cascade Layers 适合遗留代码或复杂项目。

8. 三者交集与结合

• 提出 Cascade Layers 可作为协调者，与 BEM 或 Utility Classes 结合使用，而 BEM 与 Utility Classes 结合则易冲突。
• 作者偏好 Utility Classes 结合 Cascade Layers，但认可 BEM 的价值，强调选择取决于个人与团队需求。

9. 结论
• 总结 Cascade Layers 是近年来最强大的 CSS 特性，但它与 BEM 和 Utility Classes 的本质不同（特性 vs 方法论）。
• 建议保持低特异性，并结合 Cascade Layers 设置样式优先级，以实现更高效的 CSS 管理。

author Victor Ayomipo

Smashing Magazine

CSS Cascade Layers Vs. BEM Vs. Utility Classes: Specificity Control — Smashing Magazine

CSS can be unpredictable — and specificity is often the culprit. Victor Ayomipo breaks down how and why your styles might not behave as expected, and why understanding specificity is better than relying on `!important`.

#优质博文 #前端 #node #工程化 #新动态
🕒 Node Weekly Issue #582

AI 摘要：本期 Node Weekly 聚焦 Node.js 生态系统的最新动态，重点介绍了 Node.js 通过 Amaro 1.0 向稳定支持 TypeScript 迈进的关键进展，同时涵盖了 pnpm 10.12 的全局虚拟存储功能、JavaScript 30 周年纪念以及多个实用工具和库的更新。此外，还包括对 Node.js 社区重要人物 Mikeal Rogers 的缅怀，以及对各种框架、测试工具和开发资源的深入探讨，内容详实且覆盖广泛。

1. Node.js 与 TypeScript 支持进展：
• Amaro 1.0 发布，作为 Node.js 官方工具，用于剥离 TypeScript 代码中的类型，使其能够在 Node.js 中运行，同时也可作为独立库使用。
• 这是 Node.js 将 TypeScript 支持从实验性转向稳定的重要里程碑，预计年内将在正式版本中实现稳定支持。
• Sarah Gooding 详细报道了相关进展，Marco Ippolito 在 Node Congress 2025 的演讲中进一步探讨了原生 TypeScript 支持的实现方式及当前局限性。

2. pnpm 10.12 新功能：
• 引入实验性“全局虚拟存储”功能，通过 node_modules 符号链接实现依赖共享，避免重复安装，从而提升效率和速度。

3. 社区动态与纪念：
• Isaac Z. Schlueter 发表了对 Node.js 社区重要贡献者 Mikeal Rogers 的缅怀文章，悼念其上周逝世。
• Dylan Goings 庆祝 JavaScript 诞生 30 周年，回顾其发展历程。

4. 技术文章与教程：
• 顶级 await 支持： 介绍了在现代浏览器及 Node.js（v16 以上）中，ES 模块支持顶级 await 的用法，适用于 .mjs 文件或指定为模块的 .js 文件。
• JavaScript 爬虫库推荐： 探讨了包括 Crawlee、Cheerio 等在内的最佳爬虫库，以及如何从 Node.js 使用浏览器进行爬取。
• Hono 框架与 Node.js： Hono 框架创始人 Yusuke Wada 分享了将其引入 Node.js 的经验，Hono 是一个基于 Web 标准的轻量级 Web 应用框架。
• 性能与压力测试： 介绍了三种 Node.js 测试工具（AutoCannon、Artillery、k6）的使用方法和场景。
• Nx 构建 MCP 服务器： Nx 团队分享了如何使用 Nx 构建 MCP 服务器的教程。

5. 工具与库更新（Code & Tools）：
• WelsonJS： 利用 Windows 内置 JS 引擎构建 Windows 应用，类似 Electron，适合计算能力有限的环境，支持多种 JS 替代方案和 RPC 客户端。
• Croner 9.1： 使用 cron 语法触发函数或评估表达式，v9 已迁移至 TypeScript 并引入了一些破坏性变更。
• log-vwer： 基于 Node.js 的自托管日志监控仪表板，适用于本地日志存储与搜索。
• 其他更新： 包括 & Entities 6.0（HTML/XML 实体编码/解码）、ESLint v9.29.0（支持显式资源管理语法）、LogTape 0.12（无依赖日志库）、fast-png 7.0（PNG 图像编解码）、node-llama-cpp 3.10（本地运行 LLM）、Discord.js 14.20、Ableton.js 3.7、Fastify 5.4、Mongoose 8.16、Piscina 5.1、tiff 7.0 等。

6. 由于本周内容相对较少，编辑团队回顾了未入选的库存项目，推荐了以下资源：
• FIGLet.js： 使用 FIGfont 规范将文本渲染为 ASCII 形式，适用于 CLI 工具开发。
• Stricli： Bloomberg 使用的 CLI 工具构建框架。
• Pyodide： 基于 WebAssembly 的 Python 发行版，支持浏览器和 Node.js 运行时。
• VS Code 中的 Node.js 性能分析： Pavel Romanov 展示了如何在 VS Code 中进行 Node.js 应用的基本性能分析。

#优质博文 #前端 #node #新动态 #工程化
🍊 Node Weekly #581

AI 摘要：本期 Node Weekly 聚焦 Node.js 生态系统的最新动态与技术更新，重点讨论了 Node.js 版本生命周期管理、技术提案进展以及一系列工具和库的更新。文章强调了旧版本（如 v18 及更早版本）已进入 EOL 状态，建议开发者直接升级到 v22 以获得更好的未来支持，同时介绍了 Node v24.2.0 的新功能、TC39 会议的技术提案、Jest 30 的重大改进，以及多个 Node.js 相关的工具和库的最新版本发布。此外，还涵盖了 JavaScript 生态系统的其他重要动态，如 Rolldown-Vite 带来的构建速度提升、CSS 2025 年度调查。

1. 社区动态
• Matteo Collina 指出 Node.js v18 及更早版本现已 EOL。他详细分析了这对旧版本用户意味着什么，以及为什么应该跳过活跃的 LTS v20 版本，直接升级到 v22 版本，以最大程度地适应未来发展。如果您必须继续使用旧版本，Matteo 分享了一个可供考虑的选项。
• Node v24.2.0（Current）发布：引入 import.meta.main，一个新的布尔值，用于判断当前 ES 模块是否为进程的入口点，便于在模块直接运行时执行特定代码；移除了 nghttp2 中对 HTTP/2 优先级信号的支持；使用权限系统时无需将应用程序入口点传递给 --allow-fs-read
• TC39 会议与技术提案：Sarah Gooding 总结了 TC39 近期会议讨论和推进的提案，包括 Array.fromAsync、Error.isError 和显式资源管理。

2. 测试框架与工具更新
• Jest 30 发布，带来了一系列重大改进，标志着数年来的一次重要版本更新。
• SQLite-JS：一个有趣的 SQLite 扩展，允许使用 JavaScript 编写自定义 SQLite 函数。

3. 博文教程
• Native Hot Module Reloading in Node via Module Hooks：通过模块钩子实现原生高效的“热模块”功能
• Unpacking Config and Environment Variables in Node：Liran Tal 分享了在 Node.js 中处理配置和环境变量的挑战及最佳实践
• Postgres 迁移：推荐使用 node-pg-migrate 处理 Node.js 中的 Postgres 迁移（作者：Boas Falke）。
• 构建 API：探讨如何使用 Node.js 和 gRPC 构建 API
• 在 Node 中使用 SQL 和 Sequelize：介绍在 Node.js 中使用 Sequelize 进行 SQL 操作

4. 代码与工具推荐
• Mock Service Worker：一个用于 REST/GraphQL API 模拟的库，支持拦截请求并模拟响应
• tz-lookup：基于经纬度的快速时区推断工具，以速度和大小为代价换取准确性
• 其他工具更新：包括 Babel 8 Beta、Prisma 6.9、OpenAI Node 5.2、MongoDB Node.js Driver 6.17 等多个库和框架的最新版本发布。

5. 其他 JavaScript 生态动态
• Rolldown-Vite：Evan You 宣布了基于 Rust 的快速 JavaScript 打包工具 Rolldown 的 Vite 替代包，许多开发者报告构建时间显著缩短。
• Gleam：一种针对 Erlang 和 JavaScript 运行时的语言，编译到 JS 的速度提升了 30%。
• State of CSS 2025：CSS 年度调查现已开放参与。

State of CSS 2025

Take the State of CSS survey

#优质博文 #前端 #工程化 #oxlint #linter #新动态
Announcing Oxlint 1.0

AI 摘要：Oxlint 1.0 作为首个稳定版本正式发布，这是一个基于 Rust 开发的 JavaScript 和 TypeScript 代码检查工具，性能比 ESLint 快 50~100 倍，支持超过 500 条 ESLint 规则，并在 Shopify、Airbnb 等大公司中得到应用。Oxlint 强调快速、零配置的特性，便于开发者快速上手，同时支持通过配置文件进行定制化，并提供与 ESLint 的平滑迁移工具和插件支持。未来，Oxlint 将继续优化性能、支持自定义规则和更精细的配置，团队也在不断壮大，期待社区反馈以推动项目发展。

author Boshen Chen and Cameron Clark

void(0)

Announcing Oxlint 1.0

The first stable version of Oxlint, a fast & easy-to-use Rust-powered linter for JavaScript and TypeScript, is out. Learn about its 50~100x speed advantage over ESLint, support for 500+ rules, real-world adoption by major companies, and easy migration.

#优质博文 #前端 #react #RSC #javascript #工程化
讲 RSC 讲的最明白的一集，写的太牛了。
How Imports Work in RSC

AI 摘要：本文深入探讨了 React Server Components (RSC) 中导入（import）和导出（export）机制的运作方式，重点分析了如何通过 'use client' 和 'use server' 指令在前后端环境中划分代码。作者从模块系统的基本原理出发，解释了 JavaScript 模块的单例特性及其在单一环境中的运作方式，随后扩展到前后端代码共享的挑战和解决方案，提出了 'server-only' 和 'client-only' 的“毒丸”机制来防止代码跨环境误用，并通过 RSC 的指令机制实现前后端模块系统的交互。文章旨在帮助读者构建对 RSC 的准确心智模型，同时也适用于对模块系统感兴趣的开发者。

什么是模块系统？
• 模块系统的定义：模块系统是一套规则，用于将程序拆分为文件，控制代码可见性，并将代码链接为可执行的单一程序。
• 人类需求：模块帮助开发者将复杂程序拆分为可管理的部分，限制代码可见性以保护实现细节，并促进代码复用。
• 计算机执行：计算机需要在内存中“展开”模块代码以执行程序，模块系统弥合了人类编写代码和计算机执行之间的差距。
• JavaScript 模块：通过 import 和 export 关键字实现模块化。

导入就像复制粘贴……但又不完全是
• 基本直觉：JavaScript 的模块系统设计使得 import 和 export 的效果类似于复制粘贴，最终程序在内存中展开为单一代码块。
• 与 C 语言的 #include 对比：C 的 #include 确实是直接复制粘贴，可能导致命名冲突和重复包含问题，而现代模块系统（如 JavaScript）通过自动处理避免这些问题。

JavaScript 模块是单例
• 单例特性：每个模块无论被导入多少次，其代码只执行一次，模块系统通过缓存已加载模块的导出值来实现这一点。
• 优势：避免代码重复导致输出体积膨胀；模块可保持私有状态；简化心智模型，每个模块视为单一实例。
• 实现机制：模块系统通常使用 Map 记录已加载模块及其导出值，例如在 Node.js、Webpack 等工具中均有类似逻辑。

一个程序，一个计算机
• 单一环境设计：大多数 JavaScript 程序是为单一计算机（如浏览器或 Node.js 服务器）设计的，模块系统支持从入口文件开始加载并缓存模块。
• 导入效果：导入模块时，代码被“带入”当前程序，模块保持单例特性，避免重复执行。

两个程序，两个计算机
• 前后端分离：传统上，前端和后端是运行在不同计算机上的两个独立程序，分别负责交互逻辑和 HTML/API 服务。
• 模块系统独立性：前后端各有独立的模块系统，共享代码（如 a.js）会在两个环境中分别加载，实质上是“各自的版本”。

构建失败是好事
• 代码复用风险：共享代码可能引入只适用于一侧的 API（如后端的 fs），导致另一侧构建失败。
• 构建失败的价值：构建失败提供早期反馈，迫使开发者解决代码复用问题，可选择调整代码位置或依赖关系。

仅限服务器端代码
• 问题场景：若共享代码引入服务器端敏感信息（如密钥），可能无构建错误地泄露到前端。
• 解决方案：引入 server-only “毒丸”包，标记不可进入前端的代码，前端构建时遇到则失败，强制开发者修复。
• 传递性：只需在源头文件标记 server-only，依赖链会自动传播此限制。

仅限客户端代码
• 类似机制：引入 client-only “毒丸”，防止特定前端代码（如 DOM 操作）被后端引入，构建失败以避免运行时错误。
• 细粒度控制：如 React 通过条件导出机制将 useState 等 API 标记为 client-only。

一个程序，两个计算机（RSC 视角）
• 前后端协作问题：传统方式依赖约定同步前后端代码，缺乏语法支持，易出错。
• RSC 创新：use client 指令允许后端引用前端代码而不将其引入后端，实质是“打开前端之门”，生成 <script> 标签在前端恢复；use server 则相反。
• 指令作用：非指定代码运行位置，而是创建模块系统间的“门”，用于数据传递而非代码移动。

结论
• RSC 核心：承认前后端模块系统独立性，共享代码在两侧分别存在。
• 两大机制：server-only 和 client-only 防止代码误入错误环境；use client 和 use server 提供跨环境引用和数据传递的“门”。
• 最终模型：RSC 将应用视为跨两台计算机的单一程序，拥有独立模块系统、毒丸保护和交互之门，开发者只需处理构建错误即可。

author Dan Abramov

overreacted.io

How Imports Work in RSC — overreacted

A layered module system.

#优质博文 #前端 #node #pino #logging #工程化
Production-Grade Logging in Node.js with Pino

AI 摘要：本文详细介绍了在 Node.js 应用中使用 Pino 进行生产级日志记录的全面指南。Pino 作为一种高效且快速的日志库，以其 JSON 格式输出和与现代可观测性平台的兼容性而著称。文章涵盖了 Pino 的核心功能、日志级别管理、字段自定义、上下文日志记录、序列化器和敏感数据处理、日志路由以及与 Node.js 框架和 OpenTelemetry 的集成方法。

• 引言：介绍了 Pino 自 2014 年以来的广泛应用，强调其高性能和灵活配置，Fastify 框架默认使用的日志工具。提供了安装和基本使用示例，展示了 JSON 格式输出和通过 pino-pretty 美化日志。
• Pino 日志级别：详细说明了 Pino 支持的标准日志级别（trace, debug, info, warn, error, fatal）及其对应的数值表示，默认级别为 info，并提供了通过环境变量调整日志级别的方法。
• 自定义日志级别输出：展示了如何将数值级别格式化为字符串输出，并提到后续与 OpenTelemetry 日志数据模型的集成。
• 调整 Pino 默认日志字段：介绍了如何修改默认日志字段（如时间格式、字段重命名），以及通过 formatters 自定义绑定字段（pid, hostname）或添加全局元数据（如应用版本）。
• 捕获事件和错误详情：讲解了上下文日志记录的重要性，展示了如何在 HTTP 请求中添加详细信息，并符合 OpenTelemetry 语义约定；同时介绍了如何记录 Node.js 错误及其堆栈信息。
• 使用 Pino 序列化器塑造日志：介绍了序列化器的功能，用于转换日志对象中的特定属性，包括内置序列化器（err, req, res）和自定义序列化器的创建方法。
• 敏感数据的编辑或移除：提供了使用 redact 选项自动审查或移除日志中敏感数据（如密码、信用卡信息）的方法，并支持自定义审查内容或完全移除字段。
• 使用 Pino 传输路由日志：讲解了如何通过 transport 功能将日志输出到文件或多个目标（如控制台、文件、OTLP 端点），并提及同步日志和支持的传输生态。
• 与 Node.js 框架集成：展示了 Pino 在 Fastify（默认集成，支持请求上下文追踪）和 Express（通过 pino-http 中间件）中的使用方法，包括自动日志记录和自定义配置。
• 与 OpenTelemetry 集成：介绍了通过 pino-opentelemetry-transport 将 Pino 日志转换为 OpenTelemetry 格式并发送到 OTLP 端点，支持与分布式追踪的相关性，并解决语义约定问题。

author Ayooluwa Isaiah

Dash0

Production-Grade Logging in Node.js with Pino · Dash0

This article explores Pinos core features integration with popular Nodejs frameworks and setting up a productiongrade logging pipeline with OpenTelemetry