研究报告 · 约 36,767 字 · 预计推送 4 部分

TypeScript 工程现代化：pnpm、Biome/ESLint、Vitest、Playwright 与 tsconfig 严格模式（综合报告） 未开始

目录

题记与说明

版本说明：本稿为综合报告最终稿：以 2026-10-31 同日两份章节稿综合为初稿，并已按同日独立审读意见（8 条）逐条修订（修订记录见本说明末尾）。初稿由同日两份章节稿综合而成：纵轴稿《TypeScript 工程现代化：pnpm、Biome/ESLint、Vitest、Playwright、tsconfig 严格模式》纵向发展史（2013–2026 六阶段编年）与横轴稿《TypeScript 工程现代化（个人项目模板）横向对比报告》（组件层 + 组合层对比）。综合时已消除两稿的重复表述（五组件框架、TS 7 原生编译器、pnpm 10 安全模型、Biome v2 类型感知、当前版本号此前各写了两遍），并统一了以下不一致细节：

1. TS 7 提速口径：纵轴稿称"实测提速 8–12 倍"，横轴稿称"官方声称约 10 倍、VS Code 实测 77.8s→7.5s"。统一表述为：官方在宣告时点（2025-03，基线为当时的 TS 5.x 编译器）声称约 10×，公开实测案例 8–12×（VS Code 自身类型检查 77.8s→7.5s，约 10.4×，恰在区间中点）。宣告早于 TS 6.0 的发布（2026 年春、3 月 RC），故"vs TS 6.0"口径缺乏发布后重测来源，本报告不采用。
2. pnpm 构建脚本白名单机制：纵轴稿写"pnpm approve-builds 或 onlyBuiltDependencies"，横轴稿写"v10 用 onlyBuiltDependencies、v11.23.0 起改用 allowBuilds"。统一为：pnpm 10（2025-01-07）引入"默认禁用 + 白名单审批"（pnpm approve-builds 命令与 onlyBuiltDependencies 字段），v11.23.0 起统一为 allowBuilds 字段。
3. pnpm 12 安装速度：纵轴稿"温热安装最快提升 30 倍"（pnpm 官方博客口径，对比上一代）与横轴稿"warm install 接近 Bun"（pnpm 官方基准页口径）不构成矛盾，统一表述为"官方称相对上一代最高提升 30×，第三方基准观察其水平已接近 Bun"。
4. Vitest vs Jest 速度：横轴稿同时引用"快约 10×"与"小套件实测仅快 25%"两个数字。统一表述为：官方对比文档与多数第三方基准称约一个数量级（ESM 原生 vs CommonJS shim），但小套件/冷启动场景实测差异可缩小至 25%，冷启动场景 node:test 反而最快——三个数字各属不同测量条件，不可混用。
5. noFloatingPromises 检出对比（~75%）：两稿均引用同一第三方分析。唯一定义（全文各处统一引用）：该数字测的是单条规则——Biome 的 noFloatingPromises 约能检出 typescript-eslint 同名规则可检出情形集合的 ~75%；它不是"Biome 全部类型感知规则相对 typescript-eslint 的覆盖度"。标注为"单一第三方分析，非官方承诺"。
6. Yarn dist-tags 异常：npm 实测 berry 标签为 2.4.3，与"Yarn 4 是当前主线"的普遍认知不一致，保留横轴稿"仅报告实测值、不据此下结论"的处理。
7. Cloudflare 收购 VoidZero（2026-06）：两稿均注明该条来自搜索引擎摘要、未逐字抓取官方新闻稿全文，本稿保留该来源限定。
8. 版本号复核范围：以下 6 个主包经撰稿会话以 npm view <pkg> version 复核完全一致：typescript 7.0.2、pnpm 12.16.1、vitest 5.0.5、@biomejs/biome 2.6.4、eslint 10.14.0、@playwright/test 1.64.1；修订会话（2026-10-31）以同命令抽查上述 6 包结果一致，另查得 @tsconfig/node24@24.0.5（用于 3.8 基线）。其余版本号（npm 12.2.1、yarn 1.22.22、bun 1.4.4、jest 30.5.2、cypress 16.2.1、prettier 3.9.10、oxlint 1.90.0、@tsconfig/strictest 2.0.8、@tsconfig/node22 22.0.6 等）沿用两章节稿当日核查，修订会话未复核。性能基准数字（10×、23–88%、30× 等）均为第三方或官方声称，本会话未在本机复现，与章节稿的声明一致。

修订记录（2026-10-31，按 8 条审读意见逐条处理）：① TL;DR"十八年演进/三股力量"改为"十三年演进（2013–2026）/四股力量"，与 1.0 的范围及 1.7 的四条驱动规律对齐，补回被省略的"组织形式/治理"（1.7 规律 3、3.5）。② 版本说明 8 与 2.8-2、3.7-11 的复核范围收窄为"6 个主包复核、其余沿用章节稿核查、修订会话未复核"。③ "~75%"全文统一为 2.3 的唯一定义（noFloatingPromises 单条规则、相对 typescript-eslint 同名规则可检出情形），删除"类型感知规则覆盖度"泛称，2.8-4、3.4-③、3.7-5 同步。④ 组合 C 的 tsconfig 档改为与 A 相同的 strict 精选档（strictest 仅注明适用于库作者场景），3.7-3 同步，消除与 2.6 判定的矛盾。⑤ TS 7 提速基线统一为宣告时点的 TS 5.x（1.5、1.6、版本说明 1），不采用"vs 6.0"口径。⑥ 引用落点补全：eng-ahmed 案例定位到具体文章后核对正文未见"27s→1.8s"数字，已删该数字并改用文中定性观察、补具体 URL；Turborepo 裸域名改为官方文档两页并删去未能定位的"迁移近乎 1:1"转述；Oxlint"50–100×"补 Oxc 官方出处；删除未能定位出处的"德国技术博客"对比句；Vercel 合作与 InfoWorld 2020-01-30 报道明确标注"具体 URL 未能定位"。⑦ Rome 人名订正为 Sebastian McKenzie，补实现语言时间线（宣言时点 TypeScript/Node 实现 → 2021-09-21 官宣 Rust 重写）与宣言/HN 来源，3.2 表述同步。⑧ 新增 3.8 节"最小可用模板配置"（tsconfig 推荐档全文、allowBuilds 位置与写法、biome.json、CI 排布、组合 B 的 npm 12 白名单说明、node22/node24 基线决策）。

TL;DR

截至 2026-10-31，TypeScript 工程的五根承重柱全部完成大版本换代：包管理 pnpm 12（Rust 安装引擎）、lint/格式化 Biome 2.6 或 ESLint 10（flat config 唯一）、单测 Vitest 5、E2E Playwright 1.64、类型基线 TypeScript 7（Go 原生编译器，官方声称约 10× 提速）+ strict 精选档。十三年演进（2013–2026）由四股力量驱动：Rust/Go 重写潮带来的数量级提速、供应链攻击逼出的安全默认值、"谁掌握默认值谁掌握新项目"的平台之争，以及组织形式/治理对工具寿命的决定（1.7 规律 3；3.5 视其为最可靠的先行指标）。对个人项目模板，2026 年的选型焦虑基本终结：pnpm + Biome + Vitest + Playwright + strict 精选档近乎无争议，唯一真选择题是 Biome 与 ESLint 的生态取舍（需深度插件生态时退回 ESLint）；lifecycle 脚本白名单（allowBuilds）、verbatimModuleSyntax 与 CI 里的 tsc --noEmit 兜底应固化为模板默认项（最小可用配置见 3.8）。

一、纵轴：发展脉络（2013–2026）

1.0 课题界定：五根承重柱与"个人项目模板"

"TypeScript 工程现代化"指从 2013 年前后"手工拼装 TS 工程"到 2026 年"开箱即用的现代模板"这整条演化链。五个关键词——pnpm（包管理）、Biome/ESLint（静态检查与格式化）、Vitest（单元测试）、Playwright（端到端测试）、tsconfig 严格模式（类型安全基线）——恰好对应一个 TypeScript 项目模板的五根承重柱。所谓"个人项目模板"，即开发者把这套配置固化成自己每次新项目的起点（如 Anthony Fu 的 vitesse、T3 Stack 的 create-t3-app），它的每次换代都是上述工具链集体变迁的结果。

1.1 阶段一（2013–2019）：分离时代——ESLint 诞生、TSLint 退场、strict 入主 tsconfig

这一阶段的关键词是"分裂"：包管理、lint、测试、E2E 各自为政，模板是一堆配置文件的拼盘。

驱动因素：TS 在大项目里站稳脚跟后，"类型错误也是代码错误"的观念推动 lint 工具与类型系统融合；而 TSLint 自研解析器性能不佳、无法复用 ESLint 插件生态，是被社区淘汰的根本原因。

1.2 阶段二（2020–2021）：底层重构的种子——Playwright 1.0、Rome 宣言、Vite 与模板雏形

驱动因素：SPA 复杂化让 webpack 冷启动成为痛点；ESM 与 esbuild/Rust 证明"快"可以被工程化；微软入场让浏览器自动化从"商业工具或脆弱的开源方案"变成大厂长期投入的基础设施。

1.3 阶段三（2022–2023）：旧秩序松动——pnpm 立足、CRA 除名、Rome 之死与 Biome 诞生、Vitest 1.0

驱动因素：工具链的 Rust 重写潮证明了数量级的性能收益；Jest 在 ESM/TS 上的维护迟缓；Meta 的裁员把"大公司养工具链"的幻想打破，社区 fork（Biome）与创始人公司（VoidZero，见 1.4）成为新的组织形式。

1.4 阶段四（2024）：整合之年——flat config 默认化、pnpm 9、VoidZero 成立、CRA 退役

驱动因素：配置格式统一（flat config）是 ESLint 十年债的偿还；typed linting 成本下降让"严格 + 类型感知 lint"终于可以同时出现在个人模板里；风险投资开始直接资助前端基础设施。

1.5 阶段五（2025）：安全与速度的双重革命

驱动因素：2024–2025 年 npm 供应链事件频发（含 "Miasma" 蠕虫）迫使安装模型从"信任一切脚本"转向"默认拒绝"；类型感知 lint 的性能瓶颈被 Rust 重写绕开；AI 编程助手兴起让测试框架开始内置 agent 工作流。

1.6 阶段六（2026）：全面换代——TypeScript 7、pnpm 12（Rust）、ESLint 10、Vitest 5

截至 2026-10-31，五个关键词全部完成了各自的大版本换代：

1.7 纵轴小结：五件套默认值变迁表与四条驱动规律

把纵轴投影到"一个人维护自己的项目模板"这件事上，变迁异常清晰：

时期包管理Lint/Format单测E2E类型安全
2013–2015npm 2JSHint/TSLint（手写配置）Mocha/KarmaSelenium无 strict 概念
2016–2019Yarn/npm5ESLint + TSLint 过渡JestCypressstrict 可选、逐步默认
2020–2021npm/YarnESLint + PrettierJestPlaywright 1.0 新贵vitesse 类模板固化 strict
2022–2023pnpm 起势ESLint vs Biome 萌芽Vitest 0.x→1.0Playwright 成熟bundler 解析登场
2024–2025pnpm 9/10（安全默认）ESLint 9 flat / Biome 1.x→2.0Vitest 2/3Playwright + MCPtyped linting 低成本化
2026pnpm 12（Rust）ESLint 10 / Biome 2.6Vitest 5Playwright 1.64 + AgentsTS 6/7，strict 为起点

个人模板（vitesse 这类 2020 年创建的仓库）在这六年里经历的不是"加工具"，而是五次承重柱的更换：包管理从 npm 换到 pnpm、lint 从 TSLint→ESLint→（可选）Biome、测试从 Jest→Vitest、E2E 从 Cypress→Playwright、tsconfig 从"开 strict"到"strict + bundler 解析 + 严格初始化默认"。2025–2026 年后，模板还新增了两个默认项：lifecycle 脚本白名单（pnpm 10 开创、npm 12 跟进）与 AI agents 配置（Playwright agents、Biome JS 插件），这是"现代模板"与 2024 年前模板的本质区别。

四条贯穿始终的驱动规律：

  1. 性能危机是永动机：webpack→Vite、Jest→Vitest、ESLint→Biome/tsgo，每一次换代都由"数量级变快"驱动，Rust/Go 重写是共同手段。
  2. 安全事件改写默认值：pnpm 10 与 npm 12 的脚本封锁表明，供应链攻击比 API 好看更能改变包管理器设计。
  3. 组织形式决定工具寿命：Meta 裁员杀死 Rome，社区 fork 出 Biome；Evan You 办公司保住 Vite/Vitest，再被 Cloudflare 收编——个人模板选型时，治理模式比功能清单更值得看。
  4. "默认值"之争即行业方向之争：tsc --init 默认 strict（2017）、flat config 默认（2024）、脚本默认禁用（2025）、Biome 类型感知引擎（2025）——谁掌握了默认值，谁就掌握了几百万个新项目的技术栈。

二、横轴：横向对比（2026-10-31 截面）

2.0 对比框架与竞品选取

这个课题不是单一工具，而是一套组合拳：包管理器 + Lint/格式化 + 单元测试 + E2E 测试 + 类型检查配置，共同构成一个"现代 TypeScript 个人项目模板"。因此横轴对比拆成两层：

  1. 组件层：五个组件各自与其竞品/替代方案对比；
  2. 组合层：面向"个人项目模板"这一场景，对"默认组合 vs 备选组合"做整体对比。

各组件竞品选取（时间截面：2026-10-31；场景约束：个人项目模板，而非团队 monorepo/企业级脚手架）：

组件本课题选型竞品/替代方案
包管理器pnpm 12npm 12、Yarn（Classic 1.22 / Berry）、Bun 1.4
Lint + 格式化Biome 2.6（或 ESLint 10）ESLint 10 + Prettier 3.9（组合）、Oxlint 1.90（+ oxfmt）
单元/组件测试Vitest 5Jest 30、node:test（Node 内置）
E2E 测试Playwright 1.64Cypress 16、Puppeteer、Selenium/WebdriverIO
类型检查配置tsconfig 严格模式（strict + 严格族开关）宽松默认配置、@tsconfig/strictest 全家桶、渐进式开启

一个重要的时间截面背景（纵轴 1.6 节已详述，此处只取其对横轴的影响）：TypeScript 已进入 7.x 时代——Go 原生编译器把类型检查从 CI 瓶颈变成近乎即时的反馈，客观上降低了全量严格化的门槛，"严格模式太慢"这一历史顾虑的成本结构已改变。

2.1 总览对比表

组件本课题选型（实测最新版）最强竞品竞品相对优势本课题选型相对优势个人模板推荐度
包管理器pnpm 12.16.1Bun 1.4（安装最快）/ npm 12（默认最通用）Bun 安装速度与一体化工具链；npm 零决策、兼容性最好速度 + 磁盘效率（content-addressable store）+ workspace 成熟 + v10 起默认拦截生命周期脚本的安全模型★★★★★（默认）；追求极简可用 npm
Lint/格式化Biome 2.6.4ESLint 10 + Prettier 3.9（生态最全）；Oxlint（最快）ESLint 插件生态无敌；Oxlint 原始速度更快单工具单遍完成 lint+format，速度比 ESLint 组合快 10 倍级；v2 起不依赖 tsc 的类型感知规则★★★★★；重度自定义规则需求退回 ESLint
单元测试Vitest 5.0.5Jest 30（最成熟）；node:test（零依赖最快冷启动）Jest 战斗经验与存量生态；node:test 零依赖Jest 兼容 API + 原生 ESM/TS（Vite 管线），多数基准快约一个数量级；watch UI/浏览器模式/coverage 一体★★★★★；纯后端小工具可用 node:test
E2EPlaywright 1.64.1Cypress 16（调试 DX 最佳）交互式 time-travel 调试体验多标签页/多源/iframe（进程级架构）、三浏览器 + 移动模拟、第三方基准快 23–88%、免费工具链完整★★★★★，此赛道基本无争议
tsconfigstrict + 精选严格档（见 2.6）@tsconfig/strictest 2.0.8 全家桶 / 渐进开启strictest 仅比精选档多出 exactOptionalPropertyTypes 等更激进开关以官方 strict 文档为基线按需叠加，可控性更强★★★★★；TS7 让全量严格化的编译开销趋近于零（exactOptionalPropertyTypes 的生态摩擦除外）

2.2 包管理器：pnpm vs npm vs Yarn vs Bun

维度pnpm 12.16.1npm 12.2.1Yarn Classic 1.22 / BerryBun 1.4.4
安装速度快（warm install 接近 Bun）最慢Classic 中等；Berry 较快最快（Zig 实现，官方与第三方基准一致）
磁盘效率全局 content-addressable store + 硬链接，多项目共享无共享，逐项目复制Berry PnP 有自己的优化有缓存，效率低于 pnpm store
严格性/安全v10 起默认不执行依赖生命周期脚本，需显式 onlyBuiltDependencies/v11.23.0 起改用 allowBuilds 审批脚本默认执行无同等机制（Berry 有 lockfile 严格校验）有 lockfile；脚本默认执行
workspace/monorepo最成熟（pnpm-workspace.yaml，协议化 workspace:*）workspaces 基础支持Berry 的 workspace 很强支持但相对年轻
生态采用第三方统计约 19.9% 且持续上升最高（约 56.6%）Classic 21.5% 但已停止演进增长快但占比小
个人模板适配配置少、CI 快、防供应链投毒默认开启零学习成本Classic 不建议新项目；Berry 概念负担重一体化诱惑大，但与 Node 主线行为有差异

来源：pnpm 官方基准页、Socket.dev：pnpm 10.0.0 默认阻止生命周期脚本、pnpm v10 变更讨论 #8945、pnpm 官方 2025 年终回顾、pnpm settings 文档、pnpm approve-builds 文档（v11.23.0 起 allowBuilds 取代旧字段）、采用率统计（2025）。

逐项说明：

2.3 Lint + 格式化：Biome vs ESLint + Prettier vs Oxlint

维度Biome 2.6.4ESLint 10 + Prettier 3.9Oxlint 1.90 + oxfmt
工具数量1 个（lint+format 一体）2 个 + 桥接配置（eslint-config-prettier）2 个（lint + formatter）
速度快（Rust 单遍）慢（第三方迁移案例的定性观察：大仓库上 ESLint+Prettier 管线需数秒，换 Biome 后通常不到 1 秒）最快（Oxc 官方基准自称 50–100× 于 ESLint）
类型感知规则v2（2025-06-17，代号 Biotype）起不依赖 tsc 的模块图类型推断；noFloatingPromises 单条规则约检出 typescript-eslint 同名规则可检出情形的 ~75%（单一第三方分析，唯一定义见下文逐项说明）typescript-eslint 需要 tsc 类型信息，最完整2025-08 发布类型感知预览（含 no-floating-promises）
插件生态内置规则多但插件机制有限，社区插件少碾压级：react-hooks、import、a11y、安全、框架专属插件应有尽有规则数量已超 ESLint 默认集，但深度插件少
格式化内置（与 Prettier 输出兼容度高；Turborepo 官方文档提供 Biome 集成指南与缓存注意事项）Prettier 是格式化事实标准，多语言支持最广oxfmt 较新，语言覆盖在扩展中
迁移成本biome migrate eslint --write 官方迁移器——

来源：Biome v2 官方博客、生产迁移案例：I Replaced ESLint and Prettier with Biome on Two Production Repos（Ahmed Mahmoud，2026-07-11）、Turborepo 官方指南：Biome 集成、Turborepo 官方指南：Oxc（oxlint/oxfmt，含缓存注意事项）、Oxc 官方：Oxlint 1.0 stable 公告（"50–100×"出处）、Oxc 基准页、GitHub 讨论：ESLint+Prettier 的现代替代。

逐项说明：

2.4 单元测试：Vitest vs Jest vs node:test

维度Vitest 5.0.5Jest 30.5.2node:test（Node 内置）
TS/ESM 支持原生（Vite 管线，transform 即时）需 Babel/ts-jest 或实验性 ESM 支持原生跑 TS 需 Node 类型剥离
速度（第三方基准）多数基准比 Jest 快约一个数量级（ESM 原生 vs shim）；另一个 29 用例纯 JS 套件实测：node:test 冷启动比 Jest 快约 8×、比 Vitest 快约 6×，Vitest 比 Jest 快约 25%最慢（历史包袱：CommonJS 优先 + ESM 兼容层）纯 Node 代码冷启动最快
API 兼容Jest 兼容（describe/it/mock 大体同名）原生自有 API，较简洁
配套设施watch UI、浏览器模式、coverage（v8/istanbul）、快照、内联测试生态最全、教程最多无 UI；mock/coverage 生态靠手写
依赖成本+1 依赖（连带 vite）+数依赖（ts-jest/jest-environment 等）0
版本节奏活跃：V4（2025-10-22）→ V5（2026-09-03，实测 latest 5.0.5，另有 5.1.0-beta.1）稳定但演进慢（30.x）随 Node 走，功能渐进

来源：Vitest 官方与其他运行器对比文档、Speakeasy：Vitest vs Jest 迁移实录、node:test vs Jest vs Vitest 三跑器实测计时、Sitepoint 2026 迁移基准、pkgpulse 2026 指南、r/node 社区讨论（node:test 是否够用）。

逐项说明：

2.5 E2E 测试：Playwright vs Cypress vs 其他

维度Playwright 1.64.1Cypress 16.2.1Puppeteer / Selenium
架构进程外驱动（DevTools 协议），事件源自洽应用内运行（浏览器内执行）Puppeteer：CDP 直驱；Selenium：WebDriver 协议
浏览器覆盖Chromium/Firefox/WebKit 三引擎 + 移动模拟Chromium 系为主，Firefox/WebKit 支持有限（历史遗留）Puppeteer 以 Chromium 为主；Selenium 全浏览器但 API 老旧
多标签页/多源/iframe原生支持（第三方对比中的一致结论）多标签页是其长期短板Puppeteer 可做但样板代码多
速度（第三方基准）500 用例对照实测快 23–88%较慢取决于用例
调试体验Trace Viewer、UI 模式、截图/视频交互式 time-travel 调试公认最佳最原始（日志）
商业模式MIT 开源，云服务可选开源 + Cloud 商业化（面板/录屏并行化收费）均开源
组件测试有（复用 Vitest/Pw 组件测试）有（起步更早、体验好）无

来源：Cypress vs Playwright 500 用例对照实测、TestingXperts 对比、Abstracta 2025 对比。

逐项说明：

2.6 tsconfig 严格模式：strict 基线 vs strictest 全家桶 vs 渐进式

方案内容收益成本/风险适合
宽松默认（无 strict）无无类型系统形同虚设不推荐（任何新项目）
strict: true 基线官方 strict 文档定义的捆绑：noImplicitAny、strictNullChecks、strictFunctionTypes、strictBindCallApply、strictPropertyInitialization、noImplicitThis、useUnknownInCatchVariables、alwaysStrict覆盖 90% 的实际 bug 面极低，社区事实标准所有新项目底线
strict 基线 + 精选严格族加 noUncheckedIndexedAccess、noImplicitOverride、noFallthroughCasesInSwitch、noUnusedLocals/Parameters、verbatimModuleSyntax把"索引访问可能 undefined"等高频坑纳入编译期代码需为索引访问写守卫，初学者代码量 +5~10%个人模板推荐档
@tsconfig/strictest 2.0.8 全家桶在上述之上再加 exactOptionalPropertyTypes 等理论最强exactOptionalPropertyTypes 与大量库的类型声明冲突，修复成本高类型洁癖的库作者
渐进式（eslint 式逐步开启）从宽松逐步升级遗留项目唯一可行路径需要维护 suppress 清单存量项目

逐项说明：

2.7 组合层：面向"个人项目模板"的三套组合

组合构成适合谁相对默认组合的得失
A. 默认（本课题）pnpm 12 + Biome 2.6 + Vitest 5 + Playwright 1.64 + strict 精选档 + TS 7独立开发者的全栈/前端个人项目配置文件最少、CI 最快、安全默认值最好；代价是 Biome 插件生态天花板
B. 极简派npm + node:test + Biome + （无 E2E）+ strict纯后端小工具、CLI、脚本库零外部测试依赖、心智负担最小；失去浏览器测试与 Vitest 设施
C. 保守生态派pnpm + ESLint 10 + typescript-eslint + Prettier + Jest 30（可选）+ Playwright + strict 精选档（与 A 相同；strictest 全家桶仅适用于库作者场景，见 2.6）计划开源、预期社区贡献、需要深度 lint 插件的项目生态兼容性最大；CI 时间与配置复杂度显著上升

选型判据（按影响排序）：① 是否预期外部贡献者（是 → C 的生态兼容开始有价值）；② 是否有前端/Vite 上下文（是 → Vitest 不可替代）；③ 是否介意供应链安全默认值（介意 → pnpm）；④ 是否需要多浏览器/多标签 E2E（是 → Playwright 无争议）。

2.8 横轴的风险与不确定性

  1. 基准数字均未在本机复现：约一个数量级（Vitest vs Jest）、23–88%（Playwright vs Cypress）、50–100×（Oxlint，Oxc 官方自称）、Biome 迁移案例的定性提速（数秒 → 通常不到 1 秒）、约 10×（TS7）皆为第三方声称或官方声称，不同机器/项目规模差异可能很大。
  2. 版本波动：6 个主包版本号为 2026-10-31 当日 npm 实测（撰稿会话复核、修订会话抽查一致），其余版本号沿用章节稿当日核查（修订会话未复核，见版本说明 8）；Vitest 已有 5.1.0-beta，Biome/Oxlint 迭代极快，引用时效约以季度计。
  3. TS 7 迁移摩擦未知：Go 原生编译器对个别类型体操重度库的兼容性仍在社区反馈期，模板应保留 typescript@6 降级路径说明。
  4. Biome 类型感知规则的等效性目前只有单条规则的第三方测量（noFloatingPromises ≈ typescript-eslint 同名规则可检出情形的 ~75%，唯一定义见 2.3），未测全量规则集，非官方承诺，关键规则仍建议在 CI 保留 tsc --noEmit 兜底（这与 Node 类型剥离"运行时不查类型"的要求也一致）。
  5. Yarn dist-tags 异常：实测 berry 标签为 2.4.3，与"Yarn 4 是当前主线"的普遍认知不一致，可能是标签维护滞后，本报告未据此下结论，仅报告实测值。

三、交叉洞察：两轴交汇说明了什么

3.1 横轴的"无争议"，是纵轴"默认值革命"打完的结果

横轴最显眼的事实是：五个组件里四个（pnpm、Vitest、Playwright、strict）推荐度五星且"替代方案存在但无可比性争议"，整条横轴只剩一道真选择题——Biome 还是 ESLint。这不是因为竞品消失了（Bun 更快、Jest 更成熟、Cypress 调试更好、strictest 更严），而是因为纵轴上每一场"默认值之争"都已经打完：tsc --init 默认 strict（2017）终结了"要不要严格"之争，flat config 默认（2024）与 ESLint 10 移除 eslintrc（2026）终结了配置格式之争，pnpm 10 默认禁用脚本（2025）与 npm 12 跟进终结了安全模型之争，TS 7 GA（2026）终结了"严格模式贵不贵"之争。默认值一旦写进工具的初始化行为，几百万个新项目就继承了同一套选择，横轴的对比表随之从"论证题"退化为"确认题"。对个人模板维护者，这意味着 2026 年建立模板的论证成本处于历史最低点——纵轴的表（1.7 节）里每一行"加粗的默认值"，都是横轴上一场已经结束的战争。

3.2 横轴所有"快 10 倍"的数字，是纵轴同一场重写潮在不同组件上的相位差

TS 7 约 10×（Go）、Biome 快 10 倍级（Rust）、Vitest 对 Jest 约一个数量级（复用 Vite/esbuild 管线）、pnpm 12 温热安装最高 30×（Rust）——横轴上这四个性能卖点看似各自独立，实则同源：纵轴第二阶段 Rome 宣言（2020）开启一体化工具链叙事、2021-09 Rust 化点火，第三到第六阶段扫完五个组件的 Rust/Go 重写潮。识别同源性有两个推论：其一，这些数字不是孤立的营销话术，而是同一次技术迁移的投影，可以按"谁还没被重写"预判下一个换代对象——Oxc（Oxlint/oxfmt）、Rolldown 都在 VoidZero/Cloudflare 的队列里，横轴上"最快"的 Oxlint 与 Bun 正是纵轴上下一次换代的候选；其二，重写不是银弹——Rome 有最激进的理念却死于组织，Jest 没有重写仍是可维护的成熟选择（Jest 30）。性能是换代的充分理由，治理才是换代的保票，这句话把横轴的速度表和纵轴的组织史缝在了一起。

3.3 安全事件是唯一能改写横轴对比维度的力量：包管理器的主战场已从速度转向供应链

把横轴 2.2 的 pnpm 行与纵轴对照，会发现它的卖点在三年内换了一次：2023 年 pnpm 8 时代卖的是"快 + 严格 node_modules"；到 2026 年，速度维度被 Bun（Zig）拿走、磁盘效率被各家模仿，唯一不可复制的差异是 pnpm 10 用供应链攻击的血换来的"默认不执行依赖脚本"先发优势——npm 12 直到 2026 年 7 月才跟进。这解释了横轴一个反直觉现象：pnpm 安装速度只排第二，推荐度却是五星——因为它赢在对手还没有的维度上。对个人模板的直接推论：allowBuilds 白名单不是可调的配置偏好，而是 2026 年的行业底线默认值；模板里固化它（并默认拒绝未知构建脚本）的意义，等同于 2016 年固化 lockfile。

3.4 TS 7 把类型检查的成本曲线打塌，一个变量连锁改写了四根柱子的横轴结论

纵轴第六阶段的 TS 7（约 10×）不是孤立的版本新闻，它在横轴上同时改写了四个组件的结论：① tsconfig——"strictest 全开 = CI 慢"的代价消失，唯一剩下的约束是 exactOptionalPropertyTypes 与生态类型声明的摩擦，于是推荐档是"strict + 精选严格族"而非全家桶；② lint——Biome 2.0"不依赖 tsc 的类型感知"与 TS 7 的快速类型检查一起，把"类型感知规则"从奢侈品变成默认品，typescript-eslint 的 projectService（2024）则是同一方向上的 JS 阵营回应；③ CI 结构——tsc --noEmit 的角色从"主类型检查器"降为"兜底校验"（因为 Biome 类型感知规则的等效性目前只有 noFloatingPromises 单条规则的第三方估计 ~75%，不能外推为全量覆盖，见 2.3 唯一定义；且 Node 类型剥离路线要求运行时不查类型）；④ 测试——类型检查近乎即时后，"测试跑得慢"成为工具链里更显眼的短板，反向巩固了 Vitest/Playwright 的换代合理性。一条纵轴事件横扫四根横轴柱子，这是两轴结合才能看清的杠杆结构，也解释了为什么 2026 年恰好是五柱同时换代的"共振年"。

3.5 治理形式是比功能清单更可靠的先行指标：横轴的静态快照预测不了纵轴的下一幕

把两稿中的组织事件排成序列，规律触目：TSLint（Palantir 内部优先级下降→弃用）、Rome（Meta 养、死于裁员→社区 fork 出 Biome→获 Vercel 赞助）、Jest（Meta 前端需求减弱→演进放缓）、Vite/Vitest（Evan You 创 VoidZero→被 Cloudflare 收购，商业托底升级）、Playwright/TypeScript（微软持续投入）、ESLint（无公司但基金会化运营+OpenJS 生态位）。横轴的对比表是 2026-10-31 的快照，纵轴的治理变迁才是未来三年的先行指标。给个人模板的可操作准则：优先选"有全职团队或强治理"的工具（TypeScript/Playwright/Vitest/Biome 均满足），把"个人英雄型"依赖视为最高风险项；同时警惕"被收购"是双刃剑——VoidZero 并入 Cloudflare 对 Vite+ 是利好，但也意味着路线图服从云厂商战略（AI-native web），个人模板应保持组件可替换性（这也是 Biome/ESLint 保留双路径的价值）。

3.6 纵轴的时间表揭示了换代的相位差：2026 是共振年，也是模板升级的最佳窗口

五根柱的换代并不同步：类型安全最早（2016–2017 strict 入主）、测试随后（2023 Vitest 1.0）、lint 整合居中（2024 flat config）、安全模型靠后（2025 pnpm 10）、性能重写收官（2026 pnpm 12/TS 7）——相位差约 3 年，但到 2026 年全部收敛完成。对模板维护者，这给出一个罕见的操作窗口：2026 年 Q4 建立的模板，五根柱都处于"新默认值已稳定、下一轮换代未开始"的间隙期，红利期最长。日常节奏上不必追每个大版本：模板的承重柱更换以"年"为单位即可，真正需要立即跟进的只有两类事件——安全默认值变更（如 allowBuilds）与直接影响 DX 的提速（如 TS 7）。

3.7 对用户的判断与建议（两稿合并后的最终决策清单）

  1. 新项目直接用组合 A：pnpm 12 + Biome 2.6 + Vitest 5 + Playwright 1.64 + TS 7 + strict 精选档（strict + noUncheckedIndexedAccess + noImplicitOverride + noFallthroughCasesInSwitch + noUnusedLocals/Parameters + verbatimModuleSyntax）。这是两轴共同指向的 2026 年默认答案，论证成本最低。
  2. 纯后端小工具/CLI/脚本库用组合 B：npm + node:test + Biome + strict，无 E2E。零外部测试依赖，冷启动最快；等它长出浏览器面再升 A。
  3. 计划开源、预期社区贡献用组合 C：pnpm + ESLint 10 + typescript-eslint + Prettier + Jest（可选）+ Playwright。tsconfig 与 A 相同采用 strict 精选档——组合 C 求的是生态兼容，而 2.6 已判定 strictest 全家桶恰与生态类型声明摩擦最大、只适合库作者，故不随 C 捆绑。生态兼容性最大，代价是 CI 时间与配置复杂度。
  4. Biome/ESLint 的退回条件要写进模板注释：需要 eslint-plugin-react-hooks 精确规则、a11y 插件、框架专属或自研深度规则时退回 ESLint；其余场景 Biome 的"一工具顶三配置"是净收益。迁移用 biome migrate eslint --write，保留备用分支。
  5. CI 保留 tsc --noEmit 兜底：Biome 类型感知规则的等效性目前只有 noFloatingPromises 单条规则的第三方测量（~75%，见 2.3 唯一定义），未测全量规则集；Node 类型剥离路线下运行时也不查类型，这一层兜底在 2026 年仍是必要项。
  6. lifecycle 脚本白名单固化为模板默认：pnpm allowBuilds 显式列出允许构建的依赖，默认拒绝未知脚本；这是 pnpm 10 开创、npm 12 跟进的行业底线。
  7. 拥抱可擦除语法：模板禁用 enum/namespace/参数属性，只用 type 与 const 对象——这是 verbatimModuleSyntax + Node 类型剥离 + Bun/Vite"只删类型"路线的共同要求，也是 tsconfig 严格化与运行时原生跑 TS 合流的落点。
  8. TS 7 迁移留退路：模板保留 typescript@6 降级路径说明，类型体操重度依赖先在分支上验证；编译提速带来的收益（本地即时反馈、CI 缩短）值得承担一次迁移。
  9. AI 协作配置成为新的模板默认项：Playwright Test Agents（planner/generator/healer）、Biome JS 插件、MCP 接入——2025–2026 年纵轴的最新增量，模板应预留位置而非事后加装。
  10. 不要选 Yarn，Bun 作实验分支：Yarn Classic 停止演进、Berry 概念负担重；Bun 速度上限但替换运行时，个人开发者独自排查边角问题的成本高于团队。
  11. 时效声明：6 个主包版本号为 2026-10-31 当日实测（撰稿会话复核、修订会话抽查一致），其余版本号沿用章节稿当日核查（修订会话未复核，见版本说明 8）；所有性能基准为第三方/官方声称且未在本机复现，本报告引用时效约以季度计；下一次值得整体修订的触发点是 Vitest 5.1 正式版、Biome 2.7、pnpm 12.x 去重能力的成熟与 TS 7 首个补丁周期的结束。

3.8 最小可用模板配置（按审读意见新增）

3.7 的 11 条决策要能落地，需要一套可直接复制的文件骨架。本节给出组合 A 的最小可用配置，并把组合 B 的差异单独说明。所有字段名与 flag 以各工具当期官方文档为准；版本号的复核范围见版本说明 8（6 个主包撰稿会话复核、修订会话抽查一致；@tsconfig/node24@24.0.5 为修订会话以 npm view 补查）。

3.8.1 决策补充：tsconfig extends 基线选 node24 还是 node22

结论：新模板选 @tsconfig/node24；仍停留在 Node 22 的环境用 @tsconfig/node22（22.0.6，章节稿当日核查）。 理由：① 组合 A 面向"新项目起点"（2.7），2026 年 Q4 建模板应对齐当前 LTS 线（3.6 的窗口期论断）；② 2.6 已说明 Node 22.18+/24+ 的 LTS 线类型剥离转正，node24 基线与 3.7-7 的"可擦除语法"路线同构；③ @tsconfig/node22 22.0.6 作为存量 Node 22 环境的降级选项保留。

3.8.2 tsconfig.json（strict 精选档全文，对应 2.6 推荐档与 3.7-1）

{
  // 基线：Node 24 LTS（决策见 3.8.1；@tsconfig/node24@24.0.5，修订会话 npm view 查得）。
  // Node 22 环境改用 "@tsconfig/node22/tsconfig.json"。
  "extends": "@tsconfig/node24/tsconfig.json",
  "compilerOptions": {
    // —— strict 精选档（2.6 推荐档；strictest 全家桶仅库作者场景，见 2.6 / 3.7-3）——
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    // 强制 import type 显式化；与 Node 类型剥离、Bun、Vite 的"只删类型"路线同构（2.6）
    "verbatimModuleSyntax": true,
    // 可选（TS 5.8+）：禁用 enum / namespace / 参数属性等不可擦除语法，落地 3.7-7；
    // 若所用编译器不支持该 flag，删除本行并改以 lint 约定兜底
    "erasableSyntaxOnly": true,
    // Vite/打包器项目（1.3：TS 5.0 引入 bundler 解析）；
    // 纯 Node 后端项目删除下面两行，直接沿用 extends 基线的 nodenext
    "module": "esnext",
    "moduleResolution": "bundler"
  },
  "include": ["src", "tests"]
}
组合 B / 纯后端变体：删去 module/moduleResolution 两行（回落到 extends 基线的 nodenext）；tsconfig 仅保留基线 strict（见 2.7 组合 B，不用 A 的精选严格档），其余相同。

3.8.3 allowBuilds 写在哪、怎么写（对应 3.7-6）

pnpm 的白名单写在 pnpm-workspace.yaml（pnpm v10 起把安装类设置集中于该文件，单仓库同样生效；见 1.5 所引 pnpm settings 文档），不写在 package.json：

# pnpm-workspace.yaml —— v11.23.0 起白名单字段名统一为 allowBuilds
# （v10 时代字段名为 onlyBuiltDependencies，写法位置相同，见 1.5 / 2.2）
packages:
  - .

allowBuilds:
  # 默认拒绝未知脚本，仅放行确有构建/安装脚本的依赖（按实际依赖增删）：
  - esbuild
  - sharp

交互式审批用 pnpm approve-builds，它会把选定依赖写回上述字段。模板 package.json 中同时固化 "packageManager": "pnpm@12.16.1"（版本号见版本说明 8 的复核范围），CI 的 pnpm 安装步骤据此锁定版本。模板发布时应带上一份已审批的默认清单，让"克隆即装"的默认姿势保持安全（2.2 / 3.3）。

3.8.4 biome.json 最小可用档

{
  "$schema": "https://biomejs.dev/schemas/2.6.4/schema.json",
  "vcs": { "enabled": true, "clientKind": "git", "useIgnoreFile": true },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": { "quoteStyle": "single", "semicolons": "asNeeded" }
  },
  "linter": {
    "enabled": true,
    "rules": { "recommended": true }
  }
}

3.8.5 CI 排布：tsc --noEmit 与测试的顺序（对应 3.7-5）

# .github/workflows/ci.yml 骨架
name: ci
on: [push, pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4            # 读取 package.json 的 packageManager 字段
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: pnpm
      - run: pnpm install --frozen-lockfile    # pnpm 12 默认显式 frozen-lockfile（1.6）
      - run: pnpm exec biome ci .              # lint + format 单遍，最先 fail-fast
      - run: pnpm exec tsc --noEmit            # 类型兜底（Biome 类型感知仅单条规则有第三方等效性数据，见 2.3 / 2.8-4）
      - run: pnpm exec vitest run              # 单测
      - run: pnpm exec playwright install --with-deps
      - run: pnpm exec playwright test         # E2E；量大时可拆独立 job 并缓存浏览器目录

顺序理由：biome（秒级）→ tsc --noEmit（兜底，秒级到十秒级）→ vitest → playwright，从便宜到贵逐层拦截；tsc --noEmit 不可省（3.4-③：它已从"主类型检查器"降为"兜底校验"，但兜底本身仍是必要项）。

3.8.6 组合 B 在 npm 12 下的白名单

组合 B（npm + node:test + Biome + strict，无 E2E）的差异：测试命令为 node --test（Node 22.18+/24 类型剥离已转正，可擦除语法的 .ts 可直接运行，见 2.6 / 3.7-7）；tsconfig 按 3.8.2 的"纯后端变体"；npm 12 已跟进 pnpm 的"默认禁用 lifecycle 脚本"（2026-07，见 1.5 / 1.6），但 npm 12 白名单的字段名与放置位置（package.json 或 .npmrc）本报告未获取到官方文档来源，无法给出与 pnpm allowBuilds 对应的确切写法——落地时以 npm 12 官方发布说明为准；方向与 pnpm 一致：默认拒绝、显式放行 esbuild 等二进制分发依赖。

四、参考来源

ESLint / typescript-eslint：Introducing ESLint（Zakas, 2013） · ESLint 官方 About · ESLint 9.0.0 发布（flat config 默认） · ESLint 10.0.0 发布（eslintrc 移除） · typescript-eslint v8（projectService） · Palantir TSLint 弃用声明

TypeScript：TS 2.0（strictNullChecks） · TS 2.3（--strict） · TS 5.0（bundler 解析） · TS 5.9 · A 10x Faster TypeScript 之 TS 7.0 Beta 公告 · TS 7.0 公告 · Visual Studio Magazine：TS 7 Beta 报道 · Visual Studio Magazine：TS 7 GA 报道 · strict 配置官方文档 · TSConfig Cheat Sheet · @tsconfig/bases 仓库

pnpm / npm：Flat node_modules is not the only way · pnpm v1 is out · Socket.dev：pnpm 10 默认阻止生命周期脚本 · pnpm v10 变更讨论 #8945 · pnpm approve-builds 文档 · pnpm settings 文档 · pnpm in 2025 年度回顾 · What's different in pnpm 12 · pnpm 12.0 release · pnpm 基准页 · 包管理器采用率统计（2025） · GitHub Releases API（pnpm v8.0.0 = 2023-03-27、v9.0.0 = 2024-04-16、v11.0.0 = 2026-04-28）

Biome / Rome：Rome 宣言发布当日 HN 讨论（宣言原文即仓库 README；rome.tools 原文站已并入 biomejs.dev） · Rome 介绍文（Jason Miller，第三方导读，2020-02-28） · Rome will be written in Rust（2021-09-21 官方公告，rome.tools 原文已并入 biomejs.dev，此处为 HN 入口） · Announcing Biome（2023-08-29） · Biome v1.0 · Biome v1.6（Airbnb 捐赠） · Biome v1.7（迁移路径） · Biome v1.9 · Biome v2.0（Biotype，类型感知） · Biome 官方博客（含 2.x 系列） · Vercel 合作（2025-12-01，沿用章节稿，本会话未复核）：具体公告 URL 未能定位（2026-10-31 检索），仅见官方博客首页聚合 · GitHub 讨论：ESLint+Prettier 的现代替代 · 生产迁移案例：I Replaced ESLint and Prettier with Biome on Two Production Repos（Ahmed Mahmoud，2026-07-11）（注：原稿所引"27s→1.8s"经正文核对未见——正文经其 devya.dev 镜像核对，仅含"ESLint+Prettier 数秒 → Biome 通常不到 1 秒"的定性观察，已删该数字） · Turborepo 官方指南：Biome 集成 · Turborepo 官方指南：Oxc（oxlint/oxfmt）（注：原稿"Turborepo 团队称迁移近乎 1:1"未能在 Turborepo 官方文档定位，已删，改为文档实际内容：根任务建议与升级时根任务缓存失效注意事项） · Oxc 官方：Oxlint 1.0 stable 公告（"50–100× 于 ESLint"出处） · Oxc 基准页

Vitest / Vite / VoidZero：Vite 2.0 公告 · Vitest 2.0 公告 · Vitest 官方博客（3.x/4.x/5.x） · Vitest 与其他运行器对比文档 · Announcing VoidZero Inc · Accel 种子轮投资公告 · Cloudflare 收购 VoidZero 新闻稿（来自搜索摘要） · GitHub Releases API（vitest v1.0.0 = 2023-12-04）

Playwright / E2E：microsoft/playwright 仓库 · InfoWorld《Microsoft Announces Playwright Alternative to Puppeteer》（Paul Krill，2020-01-30）——具体 URL 未能定位（2026-10-31 检索），标题/作者/日期来自检索摘要 · Playwright Release Notes · Playwright Test Agents · Cypress vs Playwright 500 用例对照实测 · TestingXperts 对比 · Abstracta 2025 对比

测试生态对照：Speakeasy：Vitest vs Jest 迁移实录 · node:test vs Jest vs Vitest 实测计时 · Sitepoint 2026 迁移基准 · pkgpulse 2026 指南 · r/node：node:test 是否够用

模板与官方默认值变迁：React：Sunsetting Create React App · GitHub API：antfu-collective/vitesse（创建于 2020-08-09） · GitHub API：t3-oss/create-t3-app（创建于 2022-05-24） · r/typescript：全严格 tsconfig 讨论

版本直查（撰稿会话执行）：npm view <pkg> version（2026-10-31）输出：typescript 7.0.2、pnpm 12.16.1、vitest 5.0.5、@biomejs/biome 2.6.4、eslint 10.14.0、@playwright/test 1.64.1；修订会话（2026-10-31）以同命令抽查上述 6 包结果一致，另查得 @tsconfig/node24 24.0.5（用于 3.8 基线）；另据两章节稿当日核查（修订会话未复核）：npm 12.2.1、yarn 1.22.22（berry 标签 2.4.3）、bun 1.4.4、jest 30.5.2、cypress 16.2.1、prettier 3.9.10、oxlint 1.90.0、@tsconfig/strictest 2.0.8、@tsconfig/node22 22.0.6。未执行：本机安装各工具做基准复现（超出范围，已在 2.8 节声明）。

思考题（读完后想一想，参考答案可展开）

  1. 报告的核心判断是“2026 年 TypeScript 个人项目模板的选型焦虑基本终结”，其依据是什么？
    参考答案

    截至 2026-10-31，五根承重柱全部完成大版本换代：pnpm 12（Rust 安装引擎）、Biome 2.6 或 ESLint 10、Vitest 5、Playwright 1.64、TypeScript 7（Go 原生编译器，官方声称约 10× 提速）加 strict 精选档。十三年演进由四股力量驱动：Rust/Go 重写潮、供应链攻击逼出的安全默认值、“谁掌握默认值谁掌握新项目”的平台之争、组织治理对工具寿命的决定。五个组件中四个推荐度五星且无争议，唯一真选择题是 Biome 与 ESLint：需深度插件生态时退回 ESLint。

  2. 包管理器对比中，pnpm 的安装速度只排第二（Bun 最快），为什么推荐度仍是五星？Bun 为何只作“实验分支”？
    参考答案

    报告认为 pnpm 的核心差异化已从“快”转向“安全默认值 + 磁盘效率”：pnpm 10（2025-01-07 发布）默认不执行依赖的 lifecycle 脚本，需白名单（v10 用 onlyBuiltDependencies，v11.23.0 起统一为 allowBuilds）显式放行，针对 npm 供应链投毒的主要攻击面做结构性防御；npm 12 直到 2026 年 7 月才跟进——pnpm 赢在对手还没有的维度上。Bun 虽安装最快，但替换了运行时，与 Node 主线行为不一致的边角问题，个人开发者独自排查的成本高于团队，故只作实验分支而非默认。

  3. 报告自己声明了哪些关键数字与结论的不确定性？由此对 Biome 的使用提出什么兜底要求？
    参考答案

    报告在 2.8 节声明：所有性能基准（TS 7 约 10×、Vitest 快约一个数量级、Playwright 快 23–88%、Oxlint 50–100× 等）均为第三方或官方声称，未在本机复现；Biome 类型感知规则的等效性只有 noFloatingPromises 单条规则的第三方测量——约能检出 typescript-eslint 同名规则可检出情形的 ~75%，不可外推为全量覆盖；TS 7 对类型体操重度库的兼容性仍在社区反馈期。因此 CI 必须保留 tsc --noEmit 兜底，模板保留 typescript@6 降级路径说明。

  4. 2026 年 Q4 新建 TypeScript 个人项目模板，报告给出的默认组合与必固化默认项是什么？纯后端小工具选什么？
    参考答案

    默认用组合 A：pnpm 12 + Biome 2.6 + Vitest 5 + Playwright 1.64 + TS 7 + strict 精选档（strict 加 noUncheckedIndexedAccess、noImplicitOverride、noFallthroughCasesInSwitch、noUnusedLocals/Parameters、verbatimModuleSyntax）。必固化项：allowBuilds 白名单写在 pnpm-workspace.yaml、默认拒绝未知脚本；CI 保留 tsc --noEmit；只用可擦除语法（禁用 enum/namespace/参数属性）；预留 Playwright Test Agents 等 AI 协作配置。纯后端小工具/CLI 用组合 B：npm + node:test + Biome + strict，无 E2E。

← 资料库今日播报 →