ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

如何安全删除死代码:Fallow trace 证据链 + fix 自动修复完整指南

如何安全删除死代码:Fallow trace 证据链 + fix 自动修复完整指南 如何安全删除死代码Fallow trace 证据链 fix 自动修复完整指南【免费下载链接】fallowCodebase intelligence for TypeScript and JavaScript. Free static analysis of code and styles: unused code, duplication, circular deps, complexity hotspots, architecture boundaries, design-system drift. Optional paid runtime layer (Fallow Runtime): hot-path review and cold-path deletion evidence from real production traffic.项目地址: https://gitcode.com/gh_mirrors/fa/fallowFallow 是一款面向 TypeScript / JavaScript 的代码库智能静态分析工具一条命令即可找出未使用的代码、循环依赖、重复代码与复杂度热点。本教程教你用fallow trace为每个待删符号建立可审计的证据链再用fallow fix安全地自动修复死代码全程零猜测、零误删。为什么删除死代码总让人心里没底删代码最怕的不是删了而是无法自证删对了这个导出真的没人引用吗还是被某个动态 import 偷偷用着删了之后测试会挂吗会波及哪些文件手动一把梭删错一个符号回滚成本远高于分析成本Fallow 的思路是把仓库读成一张依赖图——从 import 边到样式 token 全部建模然后只报告图能证明的事实。删除决策因此从感觉没人用升级为证据链闭合。快速安装与首次运行Fallow 零安装即可跑完整流水线死代码 重复 健康度无需 Node.js 运行时也不需要 TypeScript 编译器# 零安装全流水线 npx fallow # 只作为 devDependency 安装 npm install --save-dev fallow首次运行如果报出大量未使用多半是缺了入口点提示或误扫了生成文件——用npx fallow recommend可以自动检测技术栈并给出配置建议详见 README 的 Quick start 章节。 退出码约定0和1都表示运行成功1表示有发现项2才是真错误。写脚本时按这个约定分支即可。第一步删除前用 fallow trace 建立证据链双向追踪符号调用链谁在用它、它又在用谁fallow trace接受文件:符号目标沿依赖图同时向上走调用方callers、向下走被调用方callees把完整引用链打印出来# 追踪某个函数的调用链默认双向 npx fallow trace src/utils.ts:formatDate # 只看谁引用了它 / 限制追踪深度 npx fallow trace src/utils.ts:formatDate --callers --depth 3它的设计在源码中写得非常坦诚trace_chain.rs 注释明确这是 best-effort 的语法级追踪并且未解析的被调用方会如实出现在unresolved_callees里绝不静默丢弃——也就是说证据链里看不清的部分会明确告诉你看不清而不是假装没看见。默认双向追踪的逻辑见 trace_chain.rs。证明一个符号真的无人使用删除某个导出前用--trace模式让它给出未使用证明npx fallow dead-code --trace src/file.ts:symbol如果符号是类成员比如Class.methodtrace 会退回报出宿主导出的可达性与使用情况并指给你正确的成员级命令——因为成员能否被引用前提是它所在的模块本身可达。第二步用 fallow fix --dry-run 预览修复计划真正动手前先让 Fallow 展示它打算改什么npx fallow fix --dry-rundry-run 输出是纯预览哪些文件、哪些导出会被移除一个字节都不会落盘。你确认计划合理后去掉--dry-run才真正应用npx fallow fix修复计划的规划与执行分离在 fix/plan.rs 与 fix/mod.rs 中实现改动前会捕获文件哈希保证每次应用都是可验证的。第三步验证结果让删除可审计修复完成后做两件事重跑分析确认清零npx fallow dead-code应不再报出同一批符号。Fallow 的运行是确定性的相同输入产生相同输出与稳定指纹所以重跑验证是安全的。用 JSON 契约留档任何命令加--format json输出一个类型化的 JSON 文档其中每个 issue 携带actions[]并用auto_fixable标志标明哪些发现项可以交给fallow fix。把这份 JSON 存档就是这次删除的完整证据。完整输出契约见 output-schema.json。Fallow 的 fix 为什么可以放心让它删代码这是本教程最想传达的一点Fallow 对会改代码的命令采取了**失败即停止fail-closed**策略。如果你启用了--type-aware语义分析而它中途失败fix会直接终止而不是降级为语法结果继续删——因为降级会让删除集变大恰恰删掉那些本该被类型证据保住还活着的代码。这一设计意图写在 fix/mod.rs 的注释里。类成员只有在所有所属项目都报出完整的未使用证据、且声明哈希仍匹配时才会变成可自动修复项否则 Fallow 保留发现项并解释差距原因。遗留代码库可采用 baseline 隔离--save-baseline存档现有发现项之后--baseline让它们不再阻塞日常运行。语义级证据的完整契约见 type-aware-analysis.md面向 AI Agent 的合规循环见 fallow-compliance.md。安全删除死代码清单 ✅步骤命令目的1️⃣ 扫描npx fallow dead-code找出候选死代码2️⃣ 取证npx fallow trace src/file.ts:symbol验证调用链确认无人引用3️⃣ 预览npx fallow fix --dry-run审阅修复计划4️⃣ 应用npx fallow fix执行自动修复5️⃣ 验证npx fallow dead-code --format json留档证据确认清零遵循这套先取证、再预览、后修复、终验证的流程删除死代码就从一场赌博变成了一条可审计、可复现、可回滚的工程操作。【免费下载链接】fallowCodebase intelligence for TypeScript and JavaScript. Free static analysis of code and styles: unused code, duplication, circular deps, complexity hotspots, architecture boundaries, design-system drift. Optional paid runtime layer (Fallow Runtime): hot-path review and cold-path deletion evidence from real production traffic.项目地址: https://gitcode.com/gh_mirrors/fa/fallow创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表