前端后端Web框架【免费下载链接】modern.jsA progressive web framework based on React and Rsbuild.项目地址https://gitcode.com/gh_mirrors/mo/modern.js点击查看免费下载本文以 tests/skill/README.md 为核心讲解 Modern.js 仓库中 Skills 端到端验证体系的完整设计run.mjs/feature-enable.mjs两个入口如何把 fixture 复制到临时目录、驱动scan-project.mjs/migrate.mjs/enable.mjs等 skill 脚本执行真实改写并围绕「provenance来源结构不被改坏、automated应自动迁移、manual应进人工清单、blocking必须阻断且零改动」四类断言验证行为边界。读完后你将理解这套测试如何防止自动迁移脚本产生「假成功」或「半成品改写」以及如何按仓库约定新增 fixture 回归用例。一、tests/skill 的定位验证 Skills 的端到端测试tests/skill/README.md 对目录的定位只有一句话「验证 Modern.js Skills 的端到端测试」。这里的 Skills 指 skills/ 目录下两个可被 Agent 调用的技能包skills/modernjs-migrate-to-v3/把 Modern.js 2.0 应用迁移到 3.0优先做可安全自动化的依赖/配置/入口/import 改写剩余复杂项收敛为人工清单skills/modernjs-feature-enable/在已有的 v3 应用里启用 BFF、SSG、styled-components 等可选功能v3 已移除modern new该 skill 是其手动等价物。README 中给出的运行方式即整条验证链路的核心node tests/skill/run.mjs退出码非 0 表示有断言失败。实际目录里还有第二个入口 tests/skill/feature-enable.mjs用于验证 feature-enable skillBFF/SSG/Tailwind/自定义 Server 等能力的启用。两个脚本共享同一套测试范式下文分别展开。README 还指出 fixtures/v2-app/ 这类 fixture 是一个 Modern.js v2 示例应用覆盖关键 v2→v3 差异v2 依赖 plugin-tailwindcss、modern.config的dev.port/server.ssr.mode/html.appIcon、App.config/App.init/useRuntimeContext、modern-js/runtime/bff|serverimport、自定义 server。从当前 fixture 目录清单看这一初始样例已演进为规模更大的分层 fixture 集real-v2-*真实形态 baseline、v2-edge-*边界/blocker、legacy-v2-*存量 2.0 形态、v3-app-*/v3-workspace-*feature-enable 用与负向用例每个裁剪自真实项目或生成器输出的 fixture 都附带PROVENANCE.md说明来源。二、migrate-to-v3 的 e2e 测试run.mjs 的三层 fixture 与四类断言tests/skill/run.mjs 头部注释完整声明了 fixture 分三层详见各 fixture 的 PROVENANCE.mdA. 真实自动迁移 baselinereal-v2-generator-appgenerator 默认defineConfig形态验证 v2→v3 自动迁移主路径B. origin/v2 integration 真实形态applyBaseConfig包装real-v2-bff-hono/real-v2-server-config/real-v2-tailwindcss-v2验证结构性迁移进 manual、不假成功C. 存量 / 防御 / blocker edgelegacy-v2-app-config 各v2-edge-*D. 负向用例v3-workspace-app等 workspace 协议 无 v2 信号的项目验证「阻断、不改文件」。断言则按 provenance来源结构不被改坏、automated应自动迁的内容、manual应进人工的内容、blocking应直接中止分类。2.1 测试骨架复制 fixture → 跑 migrate → 断言 → 清理run.mjs 的核心基础设施只有两个函数。check记录通过/失败计数并打印✓/✗run.mjs L33-L41let pass 0; let fail 0; function check(name, cond) { if (cond) { pass 1; console.log( ✓ ${name}); } else { fail 1; console.log( ✗ ${name}); } }prepare把指定 fixture 复制到系统临时目录fs.mkdtempSync(os.tmpdir(), mj-migrate-)按需以node repo/skills/modernjs-migrate-to-v3/scripts/migrate.mjs work --to3.0.0执行迁移并返回读取辅助run.mjs L44-L67function prepare(fixture, runMigrate true) { const work fs.mkdtempSync(path.join(os.tmpdir(), mj-migrate-)); tmpDirs.push(work); copyDir(path.join(HERE, fixtures, fixture), work); if (runMigrate) { execFileSync(node, [path.join(SCRIPTS, migrate.mjs), work, --to3.0.0], { encoding: utf8 }); } return { work, read: rel fs.readFileSync(path.join(work, rel), utf8), has: rel fs.existsSync(path.join(work, rel)), report: () JSON.parse(fs.readFileSync(path.join(work, .agents/runs/modernjs-migrate/report.json), utf8)), }; }这套骨架体现了 e2e 测试的关键设计测试对象是脚本的真实产物——断言全部基于迁移后临时目录里的文件内容modern.config.ts、package.json、src/App.tsx等和.agents/runs/modernjs-migrate/report.json报告fixture 只读所有改写发生在临时目录fixture 本身永不被测试污染try/finally清理脚本结尾遍历tmpDirs逐一fs.rmSyncrun.mjs L1230-L1232最后输出结果N 通过 / M 失败fail 0时process.exit(1)run.mjs L1227-L1228与 README「退出码非 0 表示有断言失败」的约定一一对应。报告结构本身也是被测契约report.json含toVersion、targetVersionSource、changed已自动改写项、manual需人工项四个关键字段这从 skills/modernjs-migrate-to-v3/scripts/migrate.mjs 结尾的报告写入逻辑可以得到印证。2.2 A 层默认目标版本与自动迁移主路径A0 用例run.mjs L70-L92验证一个易被忽略的细节未显式传--to时migrate.mjs 默认解析 Modern.js 最新 v3 版本而不是写死 3.0.0。测试通过环境变量注入避免依赖网络execFileSync(node, [path.join(SCRIPTS, migrate.mjs), latest.work], { encoding: utf8, env: { ...process.env, MODERNJS_MIGRATE_LATEST_V3_VERSION: 3.9.9 }, }); // 断言devDependencies[modern-js/app-tools] 3.9.9 // 且 report.toVersion 3.9.9、 // report.targetVersionSource env:MODERNJS_MIGRATE_LATEST_V3_VERSION对应地scan-project.mjs 所在目录的 migrate.mjs 中确实存在MODERNJS_MIGRATE_LATEST_V3_VERSION的读取逻辑并在无法访问 npm registry 时中止而非回退到 3.0.0——这与 SKILL.md 中「不会回退到 3.0.0」的规则互为印证。A 层主路径real-v2-generator-app的断言覆盖了 README 所说的「关键 v2→v3 差异」自动迁移主路径逐条对应 SKILL.md 步骤 2 的自动完成清单断言项验证内容对应 fixture 输入[provenance] 扫描判定为 v2 项目scan-project.mjs输出含(v2)package.json 中modern-js/app-tools: 2.71.1[auto] modern-js/app-tools 升到 3.0.0依赖升级同上[provenance] 仍为 defineConfig未被改成applyBaseConfigmodern.config.ts[auto] appTools({ bundler }) → appTools()v3 默认 Rspack删除bundler参数fixture 配置plugins: [appTools({ bundler: rspack })][auto] 顶层 runtime 块已移除 合并进空 defineRuntimeConfig({})runtime: { router: true }迁入src/modern.runtime.ts同上[routes] 标准约定式路由保留 page/layout未生成 routes/index.tsx、entry.tsx、legacy-*约定式路由红线src/routes/{page,layout}.tsx[auto] 移除 v3 不支持的 modern new/upgrade scripts清理package.jsonscriptsfixture 的new: modern new、upgrade: modern upgrade[auto] manual 为空默认 app 可全自动迁移干净项目不应有假人工项—A2 用例real-v2-generator-app-js进一步验证CJSmodule.exports静态配置同样走自动迁移主路径且不被误报「函数式/动态配置」。2.3 B 层applyBaseConfig 包装下的「不假成功」语义B 层三个 fixture 均来自 origin/v2 integration 的真实形态applyBaseConfig包装。测试断言的是一套分级诚实语义如 run.mjs L204-L237 的 B1provenanceapplyBaseConfig(包装保留、runtime.router结构留在 config 内、不生成src/modern.runtime.ts——即结构性迁移「不半自动改坏」manualreport 的 manual 里必须明确出现「结构迁移未完成」applyBaseConfig字样automated文件级安全改写照常发生依赖升级、import 路径映射、tailwind 移除协议尊重workspace:*依赖保留不强升固定版本并进人工清单「随 monorepo 升级」。B2real-v2-server-config额外验证server/index.ts里的modern-js/runtime/server会被安全改写为modern-js/server-runtimeimport 路径是纯文本可无歧义替换项但server/index.tshook →modern.server.ts的语义迁移与package.json的modernConfig.runtime都进人工清单。B3real-v2-tailwindcss-v2验证 tailwind 自动移除三连删modern-js/plugin-tailwindcss依赖、生成postcss.config.cjs、移除tailwindcssPlugin()调用与 import。2.4 C 层存量形态与 30 个 edge/blocker 用例C0legacy-v2-app-config验证存量 2.0 形态的完整迁移面dev.port→server.port、App.config抽取生成src/modern.runtime.ts、modern-js/runtime/bff→modern-js/plugin-bff/client并补依赖 在 config 里按[appTools(), bffPlugin()]顺序追加插件、server/index.ts→ 可构建的server/modern.server.ts骨架含defineServerConfig、React 18 下useRuntimeContext()→useContext(RuntimeContext)、html.appIcon字符串自动迁移为{ icons: [{ src, size }] }对象同时App.init、自定义 server、ssr进人工清单。该 fixture 的 PROVENANCE.md 还说明了它存在的理由App.config/App.init/自定义server/index.ts是 v2 分支真实存量结构不作为主 happy path仅作「存量形态自动迁移 manual 边界」验证。v2-edge-*系列则是对「不假成功、不改坏」红线的系统性回归每个 fixture 对应一个已发现的风险点目录名即语义典型如不误迁v2-edge-devnested只含嵌套dev.client.port时不创建server.portC3v2-edge-tools-dev-nested的tools.dev.port不被误迁、report 也不把它标为自动迁移C25不重复已有双引号bffPluginimport 时不重复 importC8已有 react import 时不重复声明C9React default import 必须保留且useContext合并进同一 importC11不覆盖已有非空modern.runtime.ts不能被覆盖原 runtime 作为注释追加待人工合并C15v2-edge-runtime-conflict注释文案「原 modern.config 顶层 runtime」不假改写useRuntimeContext as 别名不改写、进人工清单C12BFF 无appToolsimport 且无法补 → 不写半成品plugins进 manualC14注释/字符串免疫注释里的defineConfig/runtime:/dev: { port }不参与定位、原样保留真实配置照常迁移C18/C23普通字符串里提到modern-js/runtime/bff不改写、不补依赖C22而带 magic comment 的真实import()/require()必须迁移C24事务性阻断routes/index.tsx非法形态写盘前直接阻断C30pages/foo.tsx与pages/foo/index.tsx映射冲突时事务性零改动——src/pages保留、src/routes不创建、package.json未升级、无 report.jsonC31协议语义workspace 项目补plugin-bff沿用workspace:*而非写死 3.0.0C19/C20link:协议不能照搬给别的包 → 进 manual 提示手动添加C21。C33v2-real-comprehensive是对齐真实项目迁移前形态的综合大用例一次覆盖移除modern-js/plugin-server、outputv2 字段改名cssModuleLocalIdentName→cssModules.localIdentName、disableSourceMap→sourceMap: false布尔取反、tools.webpack→rspack/webpackChain→bundlerChain、自定义入口 function-decl bootstrap 改写为createRoot()/render()、缺根routes/layout时自动生成最小布局、用户自有legacy-*目录原样保留、dev 块整块移除不留悬挂逗号等最终断言 report 对 custom server、resolveMainFields、devServer给出点名的人工项。2.5 D 层负向阻断——「不确定就不动」两个负向用例验证的是最容易被忽视的一类行为不该迁移时必须中止且零改动。以v3-workspace-app为例run.mjs L657-L714scan-project.mjs非 0 退出、不写 context.jsonambiguous 阻断直接跑migrate.mjs二次保护非 0 退出、modern.config.ts与package.json逐字节不变、不产生report.json、workspace:*不被强升固定版本。D2v3-workspace-app-string-literal进一步收紧信号判定配置里字符串字面量中写 legacy 配置示例不构成 v2 信号scan 仍然阻断。这一行为在 skills/modernjs-migrate-to-v3/scripts/scan-project.mjs 中有对应实现maskCommentsAndStringsL43-L95把注释和字符串内容替换为等长空白后再做结构/标识符信号匹配v2-only 信号清单顶层runtime、appTools({ bundler })、applyBaseConfig、plugin-tailwindcss、runtime/bff|serverimport、App.config/init、src/pages、自定义server/index等L300-L325明确排除了 v3 也存在的routes/modern.runtime.ts/appTools()workspace 协议 无任何 v2-only 信号时直接failL327-L338产出物context.json落在projectDir/.agents/runs/modernjs-migrate/。migrate.mjs 侧另有独立的前置自保护isWorkspaceProtodetectV2Signals不依赖 scan与 SKILL.md「前置自保护……不依赖 scan」的描述一致。三、fixture 工程规范为什么这些目录必须提交tests/skill/fixtures/README.md 把 fixture 定性为「测试输入性质类似 parser/compiler 的 golden cases」并给出三条治理规则值得作为同类 e2e 测试的工程参照为什么需要提交迁移类 skill 靠结构输入防回归——pages到routes、runtime冲突、workspace 协议、自定义 server、Tailwind import、BFF 导出形态等问题只有真实文件结构才能稳定复现每个 fixture 对应一个已发现的风险点目录名里的edge、real、conflict、half表示覆盖的行为边界删掉 fixture 会让对应回归只剩人工记忆体积受控——只保留最小源码、配置和PROVENANCE.md不提交node_modules、dist、.modern、.agents/runs等生成物。新增准入场景不能用现有 fixture 表达、且对应一个明确 bug/验收点/历史回归只保留复现所需的最少文件不提交安装/构建产物裁剪自真实项目或生成器输出的要补PROVENANCE.md。Reviewer 口径数量多是因为 skill 的风险来自项目形态差异而不是单个函数分支保留它们可以把用户实测问题固化成可重复验证的回归用例。以 real-v2-generator-app/PROVENANCE.md 为例它逐文件记录了来源modern.config.ts来自 origin/v2 MWA generator 模板 handlebars、package.json来自 base-template、src/routes/{layout,page}.tsx来自 entry-generator 约定式路由默认模板并明确该 fixture 的职责是「验证 v2→v3 自动迁移能力核心结构不得被改成 v3 形态」。这种溯源机制让每个 golden case 的「存在理由」可审计。四、feature-enable 的 e2e 测试feature-enable.mjstests/skill/feature-enable.mjs 复用同一套「复制 fixture → 跑skills/modernjs-feature-enable/scripts/{scan,enable}.mjs→ 断言文件与 report」范式验证目标是「从『未启用 BFF』迁到『可安装/可构建的 BFF 已启用』形态」。主要断言面BFF 自动启用v3-app-no-bff新增modern-js/plugin-bff且版本与app-tools一致configplugins追加bffPlugin()[appTools(), bffPlugin()]顺序、import 只 1 处tsconfig增加api/*别名./api/lambda/*并把api加入include同时保留原有/*别名scaffoldapi/lambda/hello.tsexport const get端到端示例接进真实页面——默认模板首页安全替换为import { get as hello } from api/hellouseEffect自定义业务首页则不覆盖、新建src/routes/bff-demo/page.tsxD8 用例专门验证自定义 welcome 首页不被覆盖。幂等第二次enable bff --json必须changed.length 0、manual 里提示「已启用」、bffPlugin()仍只 1 处默认页已接入后再跑同样changed为空。半启用修复config 有bffPlugin()调用但缺 import 绑定 → 补齐绑定且不重复加调用已有api/lambda/index.ts→ import 走api/index而非裸apialias 才能解析export async function get形态的已有 API 同样被复用D12。绑定解析边界普通字符串里的伪 import 不算绑定specifier 在但缺 export → 把 export 加进现有大括号import type不算 value 绑定另插一条 value import 且 type import 原样保留CJSmodule.exports/require配置插入const { bffPlugin } require(...)绑定而不引入 ESM importv3-app-cjs-config。SSG 值语义output.ssg: false/undefined/数组值/ssgByEntries空对象、全 false、动态值都不算已启用scan 判「未启用」启用时只翻顶层真实ssg字符串ssg: false in a string、注释、嵌套experimental: { ssg: false }原样保留output值为数组/动态表达式 → 进 manual 不动文件ssgByEntries含 true 才算已启用且已启用文案要精确点名ssgByEntries对应源码util.ts:117/adapterSSR.ts:214的语义。scaffold 分层tailwindcssRsbuild 原生脚手架装 tailwindcss/postcss/autoprefixer tailwind.config.tspostcss.config.cjstailwindCSS并自动以正确的相对路径import ../tailwind.css接入src/routes/layout.tsx与server生成含middlewares/renderMiddlewares/plugins/onError字段的server/modern.server.ts骨架、无 TS 类型语法保证取消注释不 SyntaxError的 report 必须是tier: scaffold、complete: false——骨架自动、业务语义人工microFrontend则是tier: manual输出可执行 checklist 且未改任何文件。--install的诚实失败D13v3-app-install-fail安装失败时进程非 0 退出、report.install.ok false且带approve-builds/手动安装等补救提示、stderr 进 manual但源文件改动已落盘重试路径下即使 enable 已幂等changed0仍会执行 install 且失败仍非 0——不把失败当完成。五、如何运行与在什么前提下适用在仓库根目录执行本仓库为只读环境以下命令适用于你自己 clone 的副本node tests/skill/run.mjs # migrate-to-v3 端到端验证 node tests/skill/feature-enable.mjs # feature-enable 端到端验证两个脚本均自包含不依赖 workspace 安装产物fixture 明确「不是运行产物也不会参与 workspace 安装」全程在系统临时目录操作finally中清理。适用前提Node.js 需满足 scan-project.mjs 的MIN_NODE [18, 20, 8]约束该约束针对被测项目测试脚本本身仅依赖node:child_process/fs/os/path标准库run.mjsA0 用例通过MODERNJS_MIGRATE_LATEST_V3_VERSION环境变量注入版本避免测试依赖 npm registry 网络。六、小结这套 e2e 设计可复用的要点脚本产物即契约断言不 mock直接跑真实脚本scan/migrate/enable验证真实落盘文件 report.jsonreport 的changed/manual以及 feature-enable 的tier/complete/install分层本身就是被测试的行为规格。四类断言正交provenance来源结构不被改坏/ automated该自动的必须自动/ manual该人工的必须进清单且文案点名/ blocking不确定的必须中止且事务性零改动——不改 config、不升级依赖、不产生 report。fixture golden case每个目录名编码一个风险点edge/real/conflict/halfPROVENANCE.md 记录裁剪来源新增需满足「对应明确 bug/回归」的准入把用户实测问题固化为可重复验证的回归。注释/字符串/协议免疫信号判定先做maskCommentsAndStringsimport 走真实 specifier 扫描importSpecifiers覆盖import()/require()含 magic commentworkspace/link 协议依赖不强升不照搬——这些「负向断言」的占比甚至高于正向断言是防止自动化脚本「假成功」的核心防线。进一步阅读skills/modernjs-migrate-to-v3/SKILL.md迁移 skill 的完整步骤与人工清单映射、skills/modernjs-feature-enable/SKILL.md能力矩阵与执行纪律、skills/modernjs-migrate-to-v3/scripts/scan-project.mjsv2/v3 判定与 ambiguous 阻断实现、skills/modernjs-migrate-to-v3/references/migrate-config.md 等人工项参考文档。赞分享前端后端Web框架【免费下载链接】modern.jsA progressive web framework based on React and Rsbuild.项目地址https://gitcode.com/gh_mirrors/mo/modern.js点击查看免费下载相关推荐Symfony功能测试端到端的自动化验证Symfony功能测试端到端的自动化验证 你还在手动测试Web应用的每个功能吗面对频繁迭代的业务需求重复的点击操作不仅耗时还容易出错。本文将带你掌握Sym后端Web框架Material UI 端到端测试架构解析从 Fixture 组件到 Playwright 自动化验证Material UI 端到端测试架构解析从 Fixture 组件到 Playwright 自动化验证 导读 本篇技术指南基于 Material UI 仓库的前端UI组件设计系统Detox Copilot用自然语言为 Detox 编写移动端端到端测试Detox Copilot用自然语言为 Detox 编写移动端端到端测试 导读 本文基于 Detox 官方博客发布公告系统介绍 Detox Copilot测试移动开发质量保障开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考