TodoMVC 贡献指南从提交一个可收录的框架示例到通过官方行为测试【免费下载链接】todomvcHelping you select a JavaScript framework - Todo apps for React.js, Angular, Vue and many more项目地址: https://gitcode.com/gh_mirrors/to/todomvc本篇指南系统讲解如何向 TodoMVC 仓库贡献新内容——尤其是如何提交一个新的框架示例应用Todo App。TodoMVC 是全球开发者用来横向对比 React、Angular、Vue、Svelte 等前端框架的标杆项目其贡献流程不是简单的能跑就行而是包含收录门槛审查、应用规范App Specification符合性、代码风格统一、自动化行为测试、长期维护承诺在内的一整套工程化要求。读完本文你将掌握提交前的自检清单、应用规范的核心要点、代码风格细则以及如何使用仓库自带的 Cypress 测试体系验证自己的实现是否达到官方收录标准。贡献什么不止是代码contributing.md 开篇明确了可接受的贡献形式新应用new apps、缺陷修复bug fixes、问题反馈issues等。关键流程约定有三条先认领再动手想帮忙的话先在对应的 issue 下留言说明你要处理然后开始实现。提交前先开 issue 讨论如果打算为正式提交开发一个新应用请先开一个 issue 与维护团队讨论。这样团队可以提前评估你所选用的框架判断一个符合规范的实现是否可能被接受避免你做完之后才发现方向不对。遵守行为准则项目采用 Contributor Covenant 行为准则参与即视为同意遵守其中条款。这一先讨论、后开发的流程本质上是为了把贡献者的精力导向那些真正有可能被收录的方向而不是让大量同质化实现涌入。准入门槛TodoMVC 是策展不是收藏这是理解 TodoMVC 贡献哲学最重要的一句话原文为TodoMVC is a curation, not a collection。项目的目的不是把所有框架都堆进来而是帮助开发者更容易找到自己 Web 应用的起点而不是更难。因此它无法接受每一个提交但始终欢迎解决既有问题的新颖思路novel ways。这带来两条硬性原则实现方式不限无论你的应用是用纯 JavaScript HTML 编写还是由其他语言交叉编译成现代浏览器可执行的内容都不重要创新性优先项目只关心真正带来新东西的方案已有框架/语言的细微变体只会加剧前端选择瘫痪Front-end Choice Paralysis现象不会被接受。此外你的项目需要达到一定的成熟度原文a certain level of maturity才会被考虑收录。如果框架 API 尚未稳定下来建议再等一段时间再提交示例。收录候选应用的自检清单contributing.md 明确列出如下检查项满足全部或绝大部分才值得提交检查项说明开源许可所用框架/技术栈必须存在免费且开源的版本项目年龄所用框架/技术栈至少发布1 年社区认可度框架若托管在 GitHub应有5k star其他平台需有同等量级的认可度浏览器兼容性应用必须在所有主流浏览器的最新版本上可用创新性必须带来真正新的东西已有框架/语言/现有 TodoMVC 应用的细微变体一律不通过这些门槛共同保证了收录进来的每个示例都有足够的代表性与维护基础而不是昙花一现的实验品。代码风格让代码看起来像上一位开发者写的contributing.md 要求所有代码遵循仓库的代码风格指南。该项目认为让每个贡献者的代码看起来像前一位开发者写的对长期维护最有利。以下是 codestyle.md 中的核心细则提交前请务必通读全文并在开发全程对照。通用规则使用Tab缩进字符串使用单引号语句以分号结尾使用严格模式Strict mode不留行尾空白trailing whitespace当变量同时被外层与内层作用域使用时在作用域顶部声明多条变量声明语句分开写关键字后、参数与运算符之间留空格尽早返回return early通过JSHint 与 JSCS校验保持一致性规范示例use strict; function foo(bar, fum) { var ret; var hello Hello; if (!bar) { return; } for (var i 0; i bar.length; i) { if (bar[i] hello) { ret fum(bar[i]); } } return ret; }匿名函数与严格模式使用匿名函数时在function关键字与左括号之间留一个空格(function () { use strict; var thanks mate; })();严格模式应尽量使用但绝不能全局应用而是像上面这样包裹在 IIFE 内部。注释规范行内注释有助于新用户理解代码意图但优先使用独立成行的注释行内注释与代码之间只隔一个空格//之后再加一个空格。同时建议在语句之间保留空行让函数呼吸// Ok. var removeTodo function (todoItem) { var todoModel todoItem.getModel(); // Grab the model from the todoItem. todoItem.find(.destroy).click(); // Trigger a click to remove the element from the ul. todoModel.remove(); // Removes the todo model from localStorage. }; // Better. var removeTodo function (todoItem) { // Grab the model from the todoItem. var todoModel todoItem.getModel(); // Trigger a click to remove the element from the ul. todoItem.find(.destroy).click(); // Removes the todo model from localStorage. todoModel.remove(); };RequireJS 模块格式使用 RequireJS 时按如下格式组织代码define(Block, [ jQuery, Handlebars ], function ($, Handlebars) { use strict; // Code here. });JSHint 校验提交 Pull Request 后维护者第一件事就是对你的代码运行 JSHint。你可以提前自行检查以加速评审jshint path/to/your/app/js代码块必须遵循这种 JSHint 注释风格/*global define, App */ /*jshint unused:false */提交前必读应用规范App Specification核心要点contributing.md 要求所有提交者彻底通读 应用规范。该规范是判断示例是否合格的硬性依据以下几个维度直接决定了你的应用能否通过官方测试。目录结构规范推荐如下文件结构要求尽量贴近同时尊重框架自身最佳实践index.html package.json node_modules/ css └── app.css js/ ├── app.js ├── controllers/ └── models/ readme.md组件应按职责拆分到独立文件并放入最合理的文件夹例如js/ ├── app.js ├── controllers/ │ └── todos.js └── models/ └── todo.js所有示例还必须附带 README说明框架、整体实现方式以及如需要构建流程。依赖管理除非与项目最佳实践冲突示例应使用npm管理依赖在应用根目录的package.json中声明依赖并且必须包含todomvc-common与todomvc-app-css{ private: true, dependencies: { backbone: ^1.1.2, todomvc-app-css: ^1.0.0, todomvc-common: ^1.0.1 } }node_modules中未被应用实际使用的文件文档、README、测试等应通过.gitignore排除不要混入 Pull Request。HTML 与代码要求HTML 尽量贴近官方模板完成后移除注释base.css从 assets 文件夹引用且不得改动需要调整样式时使用app.css且改动尽量少使用模板时记得更新相对路径HTML 用双引号JS 与 CSS 用单引号第三方依赖使用 npm 包手动移除运行不需要的文件用常量代替直接写 keyCodevar ENTER_KEY 13;应用不得使用预处理器Sass/CoffeeScript 等以触达最大受众为了便于横向对比框架应用在视觉与行为上应与模板及其他示例完全一致应用必须能在浏览器兼容性声明的所有浏览器中运行。功能规范对应官方行为测试规范逐条定义了应用必须实现的行为这些条目与仓库中 Cypress 行为测试的测试上下文一一对应详见下一节包括无任务时#main与#footer应隐藏新建任务输入框在页面加载时聚焦优先用autofocus属性回车创建、追加到列表并清空输入框创建前必须.trim()并判空全部完成切换复选框可统一设置所有任务状态单个任务勾选/取消时同步更新该复选框点击 Clear completed 后清除其勾选状态任务项点击复选框更新completed值并在父级li上切换completed类双击label进入编辑模式切换.editing类悬停显示删除按钮.destroy编辑进入编辑模式时隐藏其他控件显示包含任务标题的输入框并.focus()blur 与 enter 均保存编辑并移除editing类输入.trim()后判空为空则删除该任务按下escape放弃修改并退出编辑态计数器以复数形式显示活跃任务数数字用strong包裹正确复数化item0 items、1 item、2 items清除已完成按钮点击移除已完成任务无已完成任务时隐藏持久化动态将任务持久化到localStorage框架有持久化能力如Backbone.sync则用框架能力否则用原生 localStorage每条数据尽量使用id、title、completed键localStorage 命名格式为todos-[framework]编辑状态不应被持久化路由所有实现必须支持路由优先使用框架内置能力否则使用/assets目录下的Flatiron Director路由库需实现#/全部默认、#/active、#/completed#!/亦可路由变化时在模型层过滤列表并切换筛选链接的selected类在过滤状态下更新任务时列表应随之更新如在 Active 下勾选任务则应隐藏刷新后保持当前筛选状态。自动化测试用官方 Cypress 套件验证规范符合性contributing.md 明确要求使用自动化浏览器测试验证应用满足规范要求并建议把测试输出一并附到 Pull Request 里加分项。当前仓库已把这套测试体系从 Selenium 迁移为 Cypress测试基础设施与运行方式如下。测试基础设施仓库的测试链路由以下部分组成参见 tests/README.mdtests/server.js在http://localhost:8000提供仓库根目录的静态服务cypress.config.jsbaseUrl指向http://localhost:8000/examples/并开启includeShadowDom: true以支持 Web Components 示例lit、polymer 等的 Shadow DOM 穿透cypress/e2e/spec.cy.js官方行为测试的单一 spec通过Cypress.env(framework)参数化对每个示例应用运行同一套断言增删改查、切换、路由、持久化tests/cya.js批量运行器按顺序对多个框架运行 Cypress 并输出汇总表格tests/excluded.js批量运行器始终跳过的框架清单如需要托管后端的 meteor、无法离线运行的 yui、启动过慢的 cujo 等tests/knownIssues.js记录framework, test name格式的已知问题对应测试会被自动跳过用于已知坏项不阻塞 CI。运行方式运行默认主集合当前为 angular、preact、react、react-redux、svelte、vue见 tests/cya.js 中的mainFrameworks数组$ npm run test:all只测单个框架$ npm run server $ npx cypress run --env frameworkreact测指定列表$ npm run server $ node tests/cya.js -f vue -f svelte -f preact测examples/下所有未被 excluded 的框架含 backbone、knockout、ember、canjs、angular-dart 等历史示例$ npm run server $ node tests/cya.js --all交互式迭代$ npm run server $ npm run cy:open也可通过环境变量指定框架进入交互模式CYPRESS_frameworkreact npm run cy:open。这些命令与 package.json 中的脚本server、cy:open、cy:run、test、test:all一一对应例如npm run test:all实际执行start-server-and-test server http://localhost:8000 node tests/cya.js即先起静态服务再批量跑测试。若应用带构建步骤如 React、Vue、Svelte 输出到dist/Angular 输出到dist/browser/运行前需先在示例目录内执行npm run build——静态服务只提供磁盘上已存在的文件。测试上下文与规范功能的对应cypress/e2e/spec.cy.js 中的测试上下文与上一节的功能规范精确对应提交者完全可以把它当作规范的可执行版本来对照自查测试上下文验证的规范行为When page is initially opened输入框自动聚焦No Todos初始为空、隐藏#main与#footerNew Todo新增、清空输入、追加到列表底部、trim 输入Mark all as completed全选/取消全选、状态同步Item勾选/取消完成、编辑条目Editing隐藏其他控件、blur 保存、trim、空文本删除、escape 取消Counter计数显示Clear completed button文案、移除已完成项、无完成项时隐藏Persistence刷新后数据保留仅对真正持久化的应用断言RoutingActive/Completed/All 筛选、浏览器后退、选中高亮从源码看该 spec 还包含大量框架差异适配逻辑例如frameworkFolders映射各框架构建产物的入口路径见 cypress/e2e/spec.cy.js以及noLocalStorageCheck、blurAfterType等按框架裁剪断言的集合——这说明套件在设计上力求同一份断言跑所有框架因此凡是主流框架都应当能干净通过。已知边界lit 示例lit 使用三层嵌套 Shadow Roottodo-app→todo-list→todo-itemCypress 的includeShadowDom只能穿透一到两层导致.todo-list li这类选择器在添加条目后无法命中这是测试运行器的限制而非应用本身的问题详见 tests/README.md 的 Notes on lit因此 lit 未纳入默认主集合历史遗留应用examples/下大量早于现行规范的旧示例未受维护--all跑出的结果可分为三类——完全或接近全绿knockback、enyo_backbone、reagent、exoskeleton 等、因轻微规范漂移有 3–6 个失败canjs、dojo、knockoutjs、mithril 等、首个测试即级联失败backbone、emberjs、jquery、web-components、javascript-es5/6、aurelia。这些是既有状态快照不作为新提交的参照基准。Pull Request 指南contributing.md 对 PR 本身有三条硬性要求在主题分支topic branch开发不要直接在master上开发提交目标目录是默认master分支下的examples文件夹压缩提交Squash your commits写一份有说服力的 PR 描述说明为什么应该合入它以及你提议的框架/库在做法上有什么不同what the framework or library you are proposing does differently。提交新应用完整步骤清单将 contributing.md 的流程要点整理为可执行清单彻底通读 应用规范使用自动化浏览器测试确认应用满足规范要求加分项把测试输出附到 PR 中在 issue 跟踪器中搜索确认该应用此前未被提交或拒绝过参考仓库中最近的参考实现 examples/backboneBackbone 是 TodoMVC 长期维护的基准实现提交后会有维护者评审你的提交并就合入前需要修改的地方与你讨论。长期维护责任不止是一次性提交contributing.md 特别强调贡献一个新应用意味着远不止一次性的 PR。应用被收录到网站上后你需要协助维护该应用帮助解决与实现相关的问题如果应用持续损坏一段时间网站会暂时移除它直到有人提交修复 PR 并自愿承担后续维护。这一点与准入门槛中的成熟度要求互为表里——TodoMVC 收录的不只是代码还有愿意长期负责的人。浏览器兼容性贡献的应用必须兼容现代浏览器的最新版本具体为 Chrome、Firefox、Opera、Safari、IE11/Edge参见 contributing.md 的 Browser Compatibility 一节。单元测试现状与展望contributing.md 坦率地说明了单元测试的现状由于 TodoMVC 套件中应用数量庞大目前并不强制要求为应用编写单元测试才能被收录。但团队计划在未来版本中解决这一问题因为单元测试既能进一步保证一致性也能为各框架的测试编写提供参考。如果你是一位库作者或贡献者想主动为某个实现编写测试团队乐意在未来考虑收录——不过具体规则可能取决于 1.0 之后对单元测试结构的规范方式。在此期间官方行为测试Cypress 套件就是验证实现正确性的主要手段。结语不是每个框架都会被收录contributing.md 在结尾坦诚地说明鉴于当前流通的 MVC/MVVM/MV* 框架数量庞大TodoMVC不可能收录每一个框架但团队在做出决定前一定会讨论任何框架的优劣势。对于那些与项目目标不完全匹配、但仍有价值的应用官方会在项目 wiki 的 Other implementations 页面收录引用。因此最有效的贡献姿势是先开 issue 讨论框架与方案 → 对照应用规范与代码风格开发 → 用官方 Cypress 套件验证 → 提交带充分描述的主题分支 PR → 做好长期维护的准备。这一整套流程不仅适用于 TodoMVC也是任何策展型开源示例库通用的贡献方法论。【免费下载链接】todomvcHelping you select a JavaScript framework - Todo apps for React.js, Angular, Vue and many more项目地址: https://gitcode.com/gh_mirrors/to/todomvc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TodoMVC 贡献指南：从提交一个可收录的框架示例到通过官方行为测试
TodoMVC 贡献指南从提交一个可收录的框架示例到通过官方行为测试【免费下载链接】todomvcHelping you select a JavaScript framework - Todo apps for React.js, Angular, Vue and many more项目地址: https://gitcode.com/gh_mirrors/to/todomvc本篇指南系统讲解如何向 TodoMVC 仓库贡献新内容——尤其是如何提交一个新的框架示例应用Todo App。TodoMVC 是全球开发者用来横向对比 React、Angular、Vue、Svelte 等前端框架的标杆项目其贡献流程不是简单的能跑就行而是包含收录门槛审查、应用规范App Specification符合性、代码风格统一、自动化行为测试、长期维护承诺在内的一整套工程化要求。读完本文你将掌握提交前的自检清单、应用规范的核心要点、代码风格细则以及如何使用仓库自带的 Cypress 测试体系验证自己的实现是否达到官方收录标准。贡献什么不止是代码contributing.md 开篇明确了可接受的贡献形式新应用new apps、缺陷修复bug fixes、问题反馈issues等。关键流程约定有三条先认领再动手想帮忙的话先在对应的 issue 下留言说明你要处理然后开始实现。提交前先开 issue 讨论如果打算为正式提交开发一个新应用请先开一个 issue 与维护团队讨论。这样团队可以提前评估你所选用的框架判断一个符合规范的实现是否可能被接受避免你做完之后才发现方向不对。遵守行为准则项目采用 Contributor Covenant 行为准则参与即视为同意遵守其中条款。这一先讨论、后开发的流程本质上是为了把贡献者的精力导向那些真正有可能被收录的方向而不是让大量同质化实现涌入。准入门槛TodoMVC 是策展不是收藏这是理解 TodoMVC 贡献哲学最重要的一句话原文为TodoMVC is a curation, not a collection。项目的目的不是把所有框架都堆进来而是帮助开发者更容易找到自己 Web 应用的起点而不是更难。因此它无法接受每一个提交但始终欢迎解决既有问题的新颖思路novel ways。这带来两条硬性原则实现方式不限无论你的应用是用纯 JavaScript HTML 编写还是由其他语言交叉编译成现代浏览器可执行的内容都不重要创新性优先项目只关心真正带来新东西的方案已有框架/语言的细微变体只会加剧前端选择瘫痪Front-end Choice Paralysis现象不会被接受。此外你的项目需要达到一定的成熟度原文a certain level of maturity才会被考虑收录。如果框架 API 尚未稳定下来建议再等一段时间再提交示例。收录候选应用的自检清单contributing.md 明确列出如下检查项满足全部或绝大部分才值得提交检查项说明开源许可所用框架/技术栈必须存在免费且开源的版本项目年龄所用框架/技术栈至少发布1 年社区认可度框架若托管在 GitHub应有5k star其他平台需有同等量级的认可度浏览器兼容性应用必须在所有主流浏览器的最新版本上可用创新性必须带来真正新的东西已有框架/语言/现有 TodoMVC 应用的细微变体一律不通过这些门槛共同保证了收录进来的每个示例都有足够的代表性与维护基础而不是昙花一现的实验品。代码风格让代码看起来像上一位开发者写的contributing.md 要求所有代码遵循仓库的代码风格指南。该项目认为让每个贡献者的代码看起来像前一位开发者写的对长期维护最有利。以下是 codestyle.md 中的核心细则提交前请务必通读全文并在开发全程对照。通用规则使用Tab缩进字符串使用单引号语句以分号结尾使用严格模式Strict mode不留行尾空白trailing whitespace当变量同时被外层与内层作用域使用时在作用域顶部声明多条变量声明语句分开写关键字后、参数与运算符之间留空格尽早返回return early通过JSHint 与 JSCS校验保持一致性规范示例use strict; function foo(bar, fum) { var ret; var hello Hello; if (!bar) { return; } for (var i 0; i bar.length; i) { if (bar[i] hello) { ret fum(bar[i]); } } return ret; }匿名函数与严格模式使用匿名函数时在function关键字与左括号之间留一个空格(function () { use strict; var thanks mate; })();严格模式应尽量使用但绝不能全局应用而是像上面这样包裹在 IIFE 内部。注释规范行内注释有助于新用户理解代码意图但优先使用独立成行的注释行内注释与代码之间只隔一个空格//之后再加一个空格。同时建议在语句之间保留空行让函数呼吸// Ok. var removeTodo function (todoItem) { var todoModel todoItem.getModel(); // Grab the model from the todoItem. todoItem.find(.destroy).click(); // Trigger a click to remove the element from the ul. todoModel.remove(); // Removes the todo model from localStorage. }; // Better. var removeTodo function (todoItem) { // Grab the model from the todoItem. var todoModel todoItem.getModel(); // Trigger a click to remove the element from the ul. todoItem.find(.destroy).click(); // Removes the todo model from localStorage. todoModel.remove(); };RequireJS 模块格式使用 RequireJS 时按如下格式组织代码define(Block, [ jQuery, Handlebars ], function ($, Handlebars) { use strict; // Code here. });JSHint 校验提交 Pull Request 后维护者第一件事就是对你的代码运行 JSHint。你可以提前自行检查以加速评审jshint path/to/your/app/js代码块必须遵循这种 JSHint 注释风格/*global define, App */ /*jshint unused:false */提交前必读应用规范App Specification核心要点contributing.md 要求所有提交者彻底通读 应用规范。该规范是判断示例是否合格的硬性依据以下几个维度直接决定了你的应用能否通过官方测试。目录结构规范推荐如下文件结构要求尽量贴近同时尊重框架自身最佳实践index.html package.json node_modules/ css └── app.css js/ ├── app.js ├── controllers/ └── models/ readme.md组件应按职责拆分到独立文件并放入最合理的文件夹例如js/ ├── app.js ├── controllers/ │ └── todos.js └── models/ └── todo.js所有示例还必须附带 README说明框架、整体实现方式以及如需要构建流程。依赖管理除非与项目最佳实践冲突示例应使用npm管理依赖在应用根目录的package.json中声明依赖并且必须包含todomvc-common与todomvc-app-css{ private: true, dependencies: { backbone: ^1.1.2, todomvc-app-css: ^1.0.0, todomvc-common: ^1.0.1 } }node_modules中未被应用实际使用的文件文档、README、测试等应通过.gitignore排除不要混入 Pull Request。HTML 与代码要求HTML 尽量贴近官方模板完成后移除注释base.css从 assets 文件夹引用且不得改动需要调整样式时使用app.css且改动尽量少使用模板时记得更新相对路径HTML 用双引号JS 与 CSS 用单引号第三方依赖使用 npm 包手动移除运行不需要的文件用常量代替直接写 keyCodevar ENTER_KEY 13;应用不得使用预处理器Sass/CoffeeScript 等以触达最大受众为了便于横向对比框架应用在视觉与行为上应与模板及其他示例完全一致应用必须能在浏览器兼容性声明的所有浏览器中运行。功能规范对应官方行为测试规范逐条定义了应用必须实现的行为这些条目与仓库中 Cypress 行为测试的测试上下文一一对应详见下一节包括无任务时#main与#footer应隐藏新建任务输入框在页面加载时聚焦优先用autofocus属性回车创建、追加到列表并清空输入框创建前必须.trim()并判空全部完成切换复选框可统一设置所有任务状态单个任务勾选/取消时同步更新该复选框点击 Clear completed 后清除其勾选状态任务项点击复选框更新completed值并在父级li上切换completed类双击label进入编辑模式切换.editing类悬停显示删除按钮.destroy编辑进入编辑模式时隐藏其他控件显示包含任务标题的输入框并.focus()blur 与 enter 均保存编辑并移除editing类输入.trim()后判空为空则删除该任务按下escape放弃修改并退出编辑态计数器以复数形式显示活跃任务数数字用strong包裹正确复数化item0 items、1 item、2 items清除已完成按钮点击移除已完成任务无已完成任务时隐藏持久化动态将任务持久化到localStorage框架有持久化能力如Backbone.sync则用框架能力否则用原生 localStorage每条数据尽量使用id、title、completed键localStorage 命名格式为todos-[framework]编辑状态不应被持久化路由所有实现必须支持路由优先使用框架内置能力否则使用/assets目录下的Flatiron Director路由库需实现#/全部默认、#/active、#/completed#!/亦可路由变化时在模型层过滤列表并切换筛选链接的selected类在过滤状态下更新任务时列表应随之更新如在 Active 下勾选任务则应隐藏刷新后保持当前筛选状态。自动化测试用官方 Cypress 套件验证规范符合性contributing.md 明确要求使用自动化浏览器测试验证应用满足规范要求并建议把测试输出一并附到 Pull Request 里加分项。当前仓库已把这套测试体系从 Selenium 迁移为 Cypress测试基础设施与运行方式如下。测试基础设施仓库的测试链路由以下部分组成参见 tests/README.mdtests/server.js在http://localhost:8000提供仓库根目录的静态服务cypress.config.jsbaseUrl指向http://localhost:8000/examples/并开启includeShadowDom: true以支持 Web Components 示例lit、polymer 等的 Shadow DOM 穿透cypress/e2e/spec.cy.js官方行为测试的单一 spec通过Cypress.env(framework)参数化对每个示例应用运行同一套断言增删改查、切换、路由、持久化tests/cya.js批量运行器按顺序对多个框架运行 Cypress 并输出汇总表格tests/excluded.js批量运行器始终跳过的框架清单如需要托管后端的 meteor、无法离线运行的 yui、启动过慢的 cujo 等tests/knownIssues.js记录framework, test name格式的已知问题对应测试会被自动跳过用于已知坏项不阻塞 CI。运行方式运行默认主集合当前为 angular、preact、react、react-redux、svelte、vue见 tests/cya.js 中的mainFrameworks数组$ npm run test:all只测单个框架$ npm run server $ npx cypress run --env frameworkreact测指定列表$ npm run server $ node tests/cya.js -f vue -f svelte -f preact测examples/下所有未被 excluded 的框架含 backbone、knockout、ember、canjs、angular-dart 等历史示例$ npm run server $ node tests/cya.js --all交互式迭代$ npm run server $ npm run cy:open也可通过环境变量指定框架进入交互模式CYPRESS_frameworkreact npm run cy:open。这些命令与 package.json 中的脚本server、cy:open、cy:run、test、test:all一一对应例如npm run test:all实际执行start-server-and-test server http://localhost:8000 node tests/cya.js即先起静态服务再批量跑测试。若应用带构建步骤如 React、Vue、Svelte 输出到dist/Angular 输出到dist/browser/运行前需先在示例目录内执行npm run build——静态服务只提供磁盘上已存在的文件。测试上下文与规范功能的对应cypress/e2e/spec.cy.js 中的测试上下文与上一节的功能规范精确对应提交者完全可以把它当作规范的可执行版本来对照自查测试上下文验证的规范行为When page is initially opened输入框自动聚焦No Todos初始为空、隐藏#main与#footerNew Todo新增、清空输入、追加到列表底部、trim 输入Mark all as completed全选/取消全选、状态同步Item勾选/取消完成、编辑条目Editing隐藏其他控件、blur 保存、trim、空文本删除、escape 取消Counter计数显示Clear completed button文案、移除已完成项、无完成项时隐藏Persistence刷新后数据保留仅对真正持久化的应用断言RoutingActive/Completed/All 筛选、浏览器后退、选中高亮从源码看该 spec 还包含大量框架差异适配逻辑例如frameworkFolders映射各框架构建产物的入口路径见 cypress/e2e/spec.cy.js以及noLocalStorageCheck、blurAfterType等按框架裁剪断言的集合——这说明套件在设计上力求同一份断言跑所有框架因此凡是主流框架都应当能干净通过。已知边界lit 示例lit 使用三层嵌套 Shadow Roottodo-app→todo-list→todo-itemCypress 的includeShadowDom只能穿透一到两层导致.todo-list li这类选择器在添加条目后无法命中这是测试运行器的限制而非应用本身的问题详见 tests/README.md 的 Notes on lit因此 lit 未纳入默认主集合历史遗留应用examples/下大量早于现行规范的旧示例未受维护--all跑出的结果可分为三类——完全或接近全绿knockback、enyo_backbone、reagent、exoskeleton 等、因轻微规范漂移有 3–6 个失败canjs、dojo、knockoutjs、mithril 等、首个测试即级联失败backbone、emberjs、jquery、web-components、javascript-es5/6、aurelia。这些是既有状态快照不作为新提交的参照基准。Pull Request 指南contributing.md 对 PR 本身有三条硬性要求在主题分支topic branch开发不要直接在master上开发提交目标目录是默认master分支下的examples文件夹压缩提交Squash your commits写一份有说服力的 PR 描述说明为什么应该合入它以及你提议的框架/库在做法上有什么不同what the framework or library you are proposing does differently。提交新应用完整步骤清单将 contributing.md 的流程要点整理为可执行清单彻底通读 应用规范使用自动化浏览器测试确认应用满足规范要求加分项把测试输出附到 PR 中在 issue 跟踪器中搜索确认该应用此前未被提交或拒绝过参考仓库中最近的参考实现 examples/backboneBackbone 是 TodoMVC 长期维护的基准实现提交后会有维护者评审你的提交并就合入前需要修改的地方与你讨论。长期维护责任不止是一次性提交contributing.md 特别强调贡献一个新应用意味着远不止一次性的 PR。应用被收录到网站上后你需要协助维护该应用帮助解决与实现相关的问题如果应用持续损坏一段时间网站会暂时移除它直到有人提交修复 PR 并自愿承担后续维护。这一点与准入门槛中的成熟度要求互为表里——TodoMVC 收录的不只是代码还有愿意长期负责的人。浏览器兼容性贡献的应用必须兼容现代浏览器的最新版本具体为 Chrome、Firefox、Opera、Safari、IE11/Edge参见 contributing.md 的 Browser Compatibility 一节。单元测试现状与展望contributing.md 坦率地说明了单元测试的现状由于 TodoMVC 套件中应用数量庞大目前并不强制要求为应用编写单元测试才能被收录。但团队计划在未来版本中解决这一问题因为单元测试既能进一步保证一致性也能为各框架的测试编写提供参考。如果你是一位库作者或贡献者想主动为某个实现编写测试团队乐意在未来考虑收录——不过具体规则可能取决于 1.0 之后对单元测试结构的规范方式。在此期间官方行为测试Cypress 套件就是验证实现正确性的主要手段。结语不是每个框架都会被收录contributing.md 在结尾坦诚地说明鉴于当前流通的 MVC/MVVM/MV* 框架数量庞大TodoMVC不可能收录每一个框架但团队在做出决定前一定会讨论任何框架的优劣势。对于那些与项目目标不完全匹配、但仍有价值的应用官方会在项目 wiki 的 Other implementations 页面收录引用。因此最有效的贡献姿势是先开 issue 讨论框架与方案 → 对照应用规范与代码风格开发 → 用官方 Cypress 套件验证 → 提交带充分描述的主题分支 PR → 做好长期维护的准备。这一整套流程不仅适用于 TodoMVC也是任何策展型开源示例库通用的贡献方法论。【免费下载链接】todomvcHelping you select a JavaScript framework - Todo apps for React.js, Angular, Vue and many more项目地址: https://gitcode.com/gh_mirrors/to/todomvc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
