Expo 内部 CLI expotools（et）推送前三项检查：CI 校验规则、执行位置与真实踩坑记录-北京尧图网络

Expo 内部 CLI expotoolset推送前三项检查CI 校验规则、执行位置与真实踩坑记录【免费下载链接】expoAn open-source framework for making universal native apps with React. Expo runs on Android, iOS, and the web.项目地址: https://gitcode.com/GitHub_Trending/ex/expotools/CLAUDE.md是 Expo 仓库为tools/包名expotools命令别名et这份内部 CLI 工具写下的 agent 指令文件。它只有一条核心规则向expotools推送任何变更之前必须在该目录下完整跑完 CI 所执行的全部三项检查pnpm build、pnpm tsc --noEmit、pnpm lint --max-warnings 0。读完本文你能掌握这三项检查各自的校验目标与底层配置依据、为什么必须在tools/目录内执行、仓库用真实失败案例总结出的三类常见坑以及et命令的启动器launcher重建机制与et verify引擎版本同步规则从而在本地做到所见即 CI。核心规则CLAUDE.md 的三条命令tools/CLAUDE.md 全文仅三行但它不是占位文件而是一份精确到命令行的强制规则pnpm build # expo-build cjs:srcbuild — the compile that ships pnpm tsc --noEmit # typecheck under THIS tsconfig (noUnusedLocals is on) pnpm lint --max-warnings 0 # eslint; warnings fail CI (import/order, etc.)规则有两个不可省略的限定条件必须在tools/目录内执行。tools/AGENTS.md 明确说明这三条命令就是 CI 按此顺序执行的全部内容CI (.github/workflows/expotools.yml) runs these from this directory, in this order并且强调each has caught a real regression that a partial check missed——即每一项都曾抓住过只做部分检查而漏掉的真实回归。推送前必须三项全过不允许本地跑过其中一项就认为没问题。从源码结构看这三条命令分别对应 tools/package.json 中定义的 npm scriptsbuild即expo-build cjs:srcbuildCommonJS 编译产物落入build/lint即eslint .而tsc则直接调用本目录 devDependencies 中的 TypeScript 编译器。三项检查各自校验什么pnpm build可交付的编译build脚本执行expo-build cjs:srcbuild由expo-module-scriptsworkspace 依赖驱动把src/下的 TypeScript 源码编译为build/下的 CommonJS 产物。这一步校验的是编译本身能否通过——语法错误、缺失的导入、模板字符串问题等都会在这里暴露。它是 CI 流水线中the compile that ships最终交付的那次编译因此编译失败意味着产物根本不存在后面一切检查无从谈起。pnpm tsc --noEmit严格类型检查这一步在本目录的 tsconfig下做纯类型检查不产出文件。tools/tsconfig.json 中值得注意的编译选项包括strict: true—— 开启全部严格检查noUnusedLocals: true—— 未使用的局部变量直接报错这是后文真实坑之一的根源noImplicitReturns: true、noFallthroughCasesInSwitch—— 函数必须有显式返回路径switch 不允许意外穿透incremental: true且tsBuildInfoFile指向./cache/.tsbuildinfo—— 增量类型检查信息文件落在cache/目录rootDir: ./src、outDir: ./build—— 与build脚本的产物目录一致。pnpm lint --max-warnings 0警告即失败tools/eslint.config.mjs 基于eslint-config-universe的 node flat 配置叠加eslint-plugin-lodashlodash/import-scope: method即 lodash 必须按方法粒度导入如_.get而非整包并全局忽略**/build、**/cache、**/node_modules。关键在--max-warnings 0参数它把 ESLint 的0 警告作为硬门槛任何 warningAGENTS.md 特别点名import/order即 import 分组之间——node:内置模块与本地../导入之间——必须有空行分隔都会使命令非零退出。本地若只跑pnpm lint而看到几条 warning会误以为可以通过而 CI 上这一步是直接失败的。为什么必须在 tools/ 目录下运行这一点在 tools/AGENTS.md 中被记录为一个真实的失败案例npx tscfrom outside this directory resolves a differenttscand checks nothing useful. Always run viapnpmhere, or invoke./node_modules/.bin/tsc --noEmit -p .explicitly.原因是作用域问题tsc --noEmit不带-p时会查找当前目录的tsconfig.json。在tools/之外运行npx tsc解析到的是别的tsc可执行文件与别的甚至不存在的tsconfig 作用域结果是检查通过但实际什么都没检查pnpm lint同理eslint .的.指向当前目录离开tools/就套不上本目录的 eslint.config.mjsCI 侧的执行方式印证了这一点.github/workflows/expotools.yml 中typecheck 与 lint 两步都显式声明了working-directory: tools即 CI 本身就是进入该目录再跑。AGENTS.md 记录的真实踩坑tools/AGENTS.md 的 Pitfalls that produced failed pushes 一节列出了三类曾导致推送失败的坑对维护tools/的开发者包括 AI agent极具参考价值从目录外跑npx tsc如上所述会解析到错误的编译器、检查无效。正确姿势是在tools/内用pnpm tsc --noEmit或显式./node_modules/.bin/tsc --noEmit -p .。noUnusedLocals引发的连锁删除由于 tsconfig 开启了noUnusedLocals删除一个调用点却不删除对应的被调用方callee会让构建失败。文档给出的处置原则是当你要绕过或移除某个功能时把它顺带变得不可达的代码全部删干净——编译器会列出这些符号iterate until silent循环修改直到编译器不再报错。import/order分组空行node:内置导入与本地../导入分属不同 import 组组与组之间必须空一行否则在--max-warnings 0下直接失败。CI 的完整执行顺序对照本地三查.github/workflows/expotools.yml 定义了Expotools工作流在 push 到main或sdk-*分支、或 PR 涉及tools/**与自身文件时触发ubuntu-24.04 Node 24 pnpm 10 环境下按顺序执行四步编译pnpm turbo build --filter expotools...通过 Turbo 按依赖图过滤编译 expotools本地等价物即pnpm build类型检查pnpm tsc --noEmitworking-directory: toolsLintpnpm lint --max-warnings 0working-directory: tools测试pnpm testworking-directory: tools。对照 tools/package.json 可以看到test脚本定义为pnpm build node --test build/**/*.test.js——即先重新编译再用 Node 内置 test runner 跑build/下所有*.test.js。这里有一个证据边界需要说明文档CLAUDE.md / AGENTS.md列出的推送前必跑是前三项而 CI 流水线在此基础上还追加了pnpm test这一步测试用例分布在src/内的*.test.ts如 tools/src/Workspace.test.ts、tools/src/prebuilds/SPMBuild.test.ts 等。因此本地推送前的完整保障是三查自测文档强调的是前三项一项不能省。对源码树运行 et 命令的正确姿势AGENTS.md 的另一条规则针对的是如何拿当前工作树的et做冒烟测试应该用./bin/expotools command或node bin/expotools.js command——这是真实启动器自带重建逻辑不要用node build/expotools.js——文档原话是 it exists, exits 0, and runs nothing, which makes a smoke test look green while doing nothing它存在、退出码 0、但不执行任何东西会让冒烟测试看起来是绿的而实际什么也没做。从启动器源码 tools/bin/expotools.js 可以印证其工作机制maybeRebuildAndRun()约 L54-L84先读取cache/.state.json中的状态再用folder-hash对源码**/*.ts、**/*.json、expotools.js、tsconfig.json排除build/cache/node_modules计算校验和校验和变化或build/不存在时自动执行pnpm run build重建run()约 L198-L253依据重建时记录的命令 schemagetCommandsSchemaAsync()扫描build/commands/*.js并忽略*.test.js定位子命令未注册的名字会直接报错退出is not an expotools command而build/expotools.js只是 tools/src/expotools.ts 编译出的程序模块不含启动逻辑因此直接运行它退出 0 但什么都不做tools/README.md 补充了开发工作流开发 expotools 本身时一个终端挂yarn watch增量重建另一终端跑./bin/expotools COMMAND——走./bin/expotools而非全局expotools/et还能跳过更新检查。et verify引擎版本的两处同步AGENTS.md 最后一条规则涉及et verify命令的引擎版本管理dispatch、dashboard与ls三个子命令委托给expo/verify引擎以npx expo/verifypin方式运行本仓库的.verify/profile引擎的具体 pin 记录在 tools/src/commands/VerifyCommand.ts 的文件头注释中该文件的头部注释还完整列出了et verify的参数语法如et verify 48780 --fix/--retry/--watch/--runner eas。维护要点有两条引擎发新版时要升级源文件里的 pin并且必须与 .github/workflows/verify.yml 读取的仓库变量VERIFY_VERSION保持同步——该工作流中的写法是VERIFY_VERSION: ${{ vars.VERIFY_VERSION || 0.11.6 }}即仓库变量缺失时回退到已测试版本 0.11.6roundup子命令仍是原生实现文档原话 roundup is still native引擎命令语义上verify run在本地执行、verify dispatch在远端发起运行。推送前自检清单综合 tools/CLAUDE.md 与 tools/AGENTS.md向expotools推送变更前的最小自检流程是cd tools必须在目录内保证 tsconfig 与 eslint 作用域正确pnpm build——确认expo-build cjs:srcbuild编译通过pnpm tsc --noEmit——若因移除功能而报错按编译器清单把不可达代码删干净再迭代pnpm lint --max-warnings 0——0 警告才算过注意 import 分组间空行如需冒烟验证命令本身用./bin/expotools command而非node build/expotools.js若改动了 verify 相关逻辑检查VerifyCommand.ts中的引擎 pin 与VERIFY_VERSION是否一致。这套文档定规则、CI 定顺序、源码定行为的闭环使得expotools的本地验证与 CI 结果在规则层面完全一致——文档中每一项检查都对应可追溯的配置tools/tsconfig.json 的noUnusedLocals、tools/eslint.config.mjs 的规则集、.github/workflows/expotools.yml 的步骤序列也解释了为什么它要求三项全过而非跑过就行。【免费下载链接】expoAn open-source framework for making universal native apps with React. Expo runs on Android, iOS, and the web.项目地址: https://gitcode.com/GitHub_Trending/ex/expo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Expo 内部 CLI expotools（et）推送前三项检查：CI 校验规则、执行位置与真实踩坑记录

相关推荐

基于B站用户行为分析系统Python毕业设计实战：从表结构到性能优化

基于大数据的智能留学推荐系统设计与实现

PythonRobotics 纯追踪（Pure Pursuit）路径跟踪实战：算法原理、源码逐行解析与仿真运行指南

更多资讯

TVBoxOSC 上手指南：不编译也能拿到最新电视盒子版 TVBox

Python面向对象编程：类与对象、三大特性及实战应用

Kivy跨平台应用开发实战：从环境搭建到发布

Coding Conventions

Calibre 格式转换教程：30 秒把 PDF 变成手机 EPUB

Claude Code Router 怎么接入 Kimi CLI 并用 /model 在多个可用模型间切换

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？