数据集开发工具【免费下载链接】browser-compat-dataBrowser compatibility data for Web technologies as displayed on MDN项目地址https://gitcode.com/gh_mirrors/br/browser-compat-data点击查看免费下载mdn/browser-compat-data简称 BCD是 MDN 维护的机器可读 Web 技术浏览器兼容性数据集覆盖 Web API、CSS、JavaScript 等十余个领域。当项目需要对大规模 JSON 数据做结构性调整时BCD 采用了一套类似数据库迁移database migration的流程自动化脚本、配套测试、择机合入。本文基于 docs/migrations.md 的完整流程说明结合仓库中真实存在的迁移脚本与测试用例讲解如何为 BCD 编写、测试并执行一次数据迁移读完你将掌握迁移脚本的命名规范、实现模式、测试方法与协作节奏。一、什么时候该走迁移流程BCD 的迁移流程针对的是适合自动化、影响大量文件、且是对既有数据进行修改的变更。与普通 PR 相比这类变更如果靠人工逐个文件修改会耗费大量时间也容易出错。迁移流程的核心价值在于自动化把重复性修改写成脚本一键跑完全仓库数据可验证脚本必须配有测试证明它只做了预期修改、没有引入无关变更低扰动选择对他人影响最小的时机执行避免与大量在审 PR 冲突。如果变更规模较小或者根本无法自动化则不应该走迁移流程直接开 pull request 或 issue 即可。例如给某个 API 修正一个版本号、给某个条目补充 notes这类单点修改直接走常规 PR。BCD 数据本身是高度结构化的 JSON每个特性由__compat对象描述详见 schemas/compat-data-schema.md其中support字段按浏览器记录版本支持情况status字段记录实验性、标准轨道与废弃状态。正是因为数据结构高度规整才使得全局改写类迁移成为可能。二、Step 1在 issue 中宣布意图一次规范的迁移从创建或复用 issue开始。这个 issue 是整个迁移过程的讨论与跟踪场所需要做到清晰描述变更内容一次聚焦一类变更不要混入多个不相关的改动用 checklist 规划与跟踪进度把写脚本 → 测试 → 合并 → 执行 → 收尾拆成可勾选的步骤等待反馈在进入下一步之前给维护者留出评审与提出异议的时间。三、Step 2创建并测试迁移脚本3.1 脚本目录与命名规范迁移脚本统一放在 scripts/migrations 目录下命名遵循###-description.js模式###是迁移的顺序编号如002、007、010description是对该迁移的简短描述如remove-webview-flags。文档中提到的首个迁移是001-sort-features.js。当前仓库中保留的迁移脚本包括脚本配套测试迁移内容002-remove-webview-flags.js002-remove-webview-flags.test.js移除 WebView Android 中带 flags 的支持语句007-experimental-false.js007-experimental-false.test.js根据引擎支持数自动修正experimental状态010-set-oculus-to-mirror.js—将缺失的oculus支持设为mirror011-set-webview-ios-to-mirror.js—将缺失的webview_ios支持设为mirror012-descriptions-to-md.js—将description中的code标签转换为 Markdown 反引号3.2 脚本的通用实现骨架从源码结构看BCD 迁移脚本大多遵循同一套reviver 文件回写 递归遍历模式。以 002-remove-webview-flags.js 为例// 核心转换函数作为 JSON.parse 的 reviver按 key 逐层处理 export const removeWebViewFlags (key, value) { if (key __compat) { if (value.support.webview_android ! undefined) { // 过滤掉带 flags 的语句只保留无 flags 的版本 // ... if (result.length 0) { value.support.webview_android { version_added: false }; } else if (result.length 1) { value.support.webview_android result[0]; } else { value.support.webview_android result; } } } return value; }; // 文件级处理读文件 → JSON.parse(reviver) → 格式化 → 有变化才写回 export const fixWebViewFlags (filename) { let actual fs.readFileSync(filename, utf-8).trim(); let expected JSON.stringify( JSON.parse(actual, removeWebViewFlags), null, 2, ); if (IS_WINDOWS) { // 防止 Windows 上 git.core.autocrlf 造成的误判 actual actual.replace(/\r/g, ); expected expected.replace(/\r/g, ); } if (actual ! expected) { fs.writeFileSync(filename, expected \n, utf-8); } };其中几个关键设计值得迁移作者借鉴reviver 模式利用JSON.parse(text, reviver)按 key 深度优先回调的特性只对__compat节点动手天然具备只改数据不改结构的语义幂等与零改动跳过actual ! expected时才写回文件保证重复运行不会产生 diff、不会无谓触碰文件 mtimeWindows 换行处理借助 lint/utils.js 导出的IS_WINDOWS常量避免 CRLF 造成的误判CLI 入口脚本尾部用es-main判断是否被直接执行支持传入单个路径否则默认遍历dataFoldersMinusBrowsers即api、css、html、http、javascript、manifests、mathml、mediatypes、svg、webassembly、webdriver、webextensions十二个数据目录定义见 scripts/lib/data-folders.jsif (esMain(import.meta)) { if (process.argv[2]) { load(process.argv[2]); } else { load(...dataFoldersMinusBrowsers); } }3.3 迁移中的核心数据对象迁移脚本操作的核心是__compat对象与support字段。理解它们的形态详见 schemas/compat-data-schema.md有助于编写正确的转换逻辑每个特性的__compat下有一个必填的support对象按浏览器标识符如chrome、firefox、safari、webview_android等记录支持情况每个浏览器的值可以是一个simple_support_statement对象、多个语句组成的数组或字符串mirror表示自动镜像上游浏览器数据语句对象中常见字段包括version_added必填可为版本字符串、false、≤版本或preview、version_removed、prefix、alternative_name、flags、partial_implementation、notes等。例如002-remove-webview-flags的语义是WebView Android 中仅靠 flag 开启的功能不再值得记录对应 README 中removal of irrelevant flag data的准则因此把带flags的语句直接移除若该浏览器只剩 flag 语句则整条支持改写为version_added: false。3.4 配套测试证明只做该做的改动脚本必须附带一个或多个测试用于证明迁移做出了描述的修改且没有引入其他无关修改。测试文件同样放在scripts/migrations/目录命名为###-description.test.js使用 Node.js 内置的node:test与node:assert/strict编写。以 002-remove-webview-flags.test.js 为例它通过输入/期望输出成对用例驱动const tests [ { input: { __compat: { support: { webview_android: { version_added: 61, flags: [ { type: preference, name: #service-worker-payment-apps, value_to_set: Enabled, }, ], }, }, // ... }, }, output: { __compat: { support: { webview_android: { version_added: false, }, }, // ... }, }, }, // 更多用例无 flags 语句原样保留、数组语句中只保留无 flags 项等 ]; describe(migration scripts, () { it(removeWebViewFlags() works correctly, () { for (const test of tests) { const expected test.output; const output JSON.parse(JSON.stringify(test.input), removeWebViewFlags); assert.deepEqual(output, expected); } }); });而 007-experimental-false.test.js 则展示了基于真实 BCD 结构的测试方式构造api.fetch.__compat这样的嵌套数据调用fixExperimental(bcd)后断言status.experimental是否被翻转。其四条用例恰好覆盖了迁移规则的边界Chrome Firefox Safari 三引擎都支持 →experimental从true改为false只有 Chrome Firefox 两引擎支持 → 同样改为false仅 Chrome 一个引擎支持 → 保持experimental: true不变桌面 Chrome/Safari 不支持但移动端chrome_android/safari_ios支持 → 视为多引擎改为false。对照 007-experimental-false.js 的源码可以确认其判定逻辑先收集无flags、无prefix、无alternative_name且version_added存在、version_removed为空的支持语句所属浏览器再映射到 Blink、Gecko、WebKit 三个引擎最后统计命中引擎数超过一个才把experimental置为false。这与 schemas/compat-data-schema.md 中对experimental字段通常意味着被两个或更多浏览器引擎实现的约定一致。3.5 提交 PR 与审批要求脚本和测试就绪后需要开一个 pull request。该 PR 要被接受必须经过至少一位 project owner 的评审与批准。Owner 的职责与审批边界见 GOVERNANCE.md迁移脚本这类基础设施变更非数据更新只有 Owners 有权合并这与Peers 可合并 compat data PR、但不能合并 schema/linter/基础设施变更的权限划分一致。四、Step 3执行迁移迁移脚本被合并后需要与一位 project owner 协调时间来完成迁移。执行时的分工是一位项目参与者在约定时间运行迁移脚本并打开一个 PROwner负责合并该 PR。选择执行时机时要先检查在审的 PR评估潜在冲突。如果仍有大型人工 PR 处于评审中应等待它们合并后再执行迁移否则迁移生成的全量 diff 会与这些 PR 产生大量冲突增加所有人的返工成本。执行迁移脚本的命令形如脚本支持传入指定路径也可不加参数默认遍历全部数据目录# 默认处理所有数据目录dataFoldersMinusBrowsers node scripts/migrations/007-experimental-false.js # 或只处理指定目录/文件 node scripts/migrations/007-experimental-false.js api css由于脚本是幂等设计重复运行不会产生多余 diff这给运行前检查、运行后复核提供了安全余量。五、Step 4收尾如果适用迁移完成后再提交一个 PR引入与该迁移相关的新 linter 检查或其他质量强制工具。这一步的意义在于把迁移的成果固化为长期约束——例如迁移把某类数据全部改写后应让 linter 从此拒绝旧格式重新出现防止数据回退。最后在最初的 issue 中宣布迁移完成为整个流程画上句号。这也呼应了第一步issue 作为全程讨论与跟踪场所的设计。六、从真实迁移脚本看数据改写手法仓库中留存的迁移脚本提供了三种典型的数据改写手法可作为后续编写迁移的参考模板6.1 语句级过滤002-remove-webview-flags对webview_android的支持语句数组做过滤只保留不含flags的语句若过滤后为空则置为version_added: false只剩一条则简化为对象多条则保留数组。这是一种典型的删除某类语句迁移。6.2 跨浏览器派生数据010-set-oculus-to-mirror与011-set-webview-ios-to-mirror这两个脚本结构几乎相同都是为缺失的浏览器键写入mirror字符串export const doSetOculusToMirror (key, value) { if (key __compat) { if (value.support.oculus undefined) { value.support.oculus mirror; } } return value; };mirror是 BCD 中特殊的支持语句值表示该浏览器的数据自动镜像自其上游浏览器如 Oculus 镜像 Chrome、WebView iOS 镜像 Safari具体映射关系定义在各浏览器的browsers/browser.json中。这类迁移的价值在于与其为每个特性手工补一份可能过期的版本号不如统一用mirror声明派生关系让构建期自动解析镜像机制详见 schemas/compat-data-schema.md。6.3 文本格式规范化012-descriptions-to-mdexport const doDescriptionsToMarkdown (key, value) { if (key __compat) { if (value.description) { value.description value.description.replace(/\/?code/g, ); } } return value; };将description中残留的 HTMLcode//code标签替换为 Markdown 反引号使描述字段与 schema 中description 可用 Markdown 格式化的约定保持一致。这类文本层迁移同样受益于 reviver 模式——不需要递归遍历JSON.parse天然会访问到每个__compat节点。七、迁移质量验证测试、lint 与数据检查迁移脚本合并前建议结合仓库现有的验证体系进行完整检查详见 docs/testing.md单测npm run unittest会运行包括scripts/migrations/*.test.js在内的全部测试完整验证npm test依次执行格式化检查ESLint Prettier tsc、数据 lint 与单元测试其中 lint/lint.js 会加载所有数据目录并按 file / browser / feature / tree 四级作用域跑 linter定向检索npm run traverse -- [options] [folder]可在迁移前后检索特定浏览器、特定取值的数据分布例如npm run traverse api,javascript -- -b webview_android -f mirror可确认 WebView 条目是否全部镜像化用于验证迁移效果统计观察npm run stats [folder]可观察 exact / ranged 值占比的变化。八、小结BCD 的迁移流程本质上是一条可审计的大规模数据变更流水线issue 跟踪 → 自动化脚本 测试 → Owner 审批 → 择机执行 → linter 固化 → issue 宣布完成。对于数据规模达上万特性的仓库这套流程把修改全仓库数据从高风险的人工操作变成了可重复、可验证、可追溯的工程实践。如果后续你需要为 BCD 贡献类似的大规模改写遵循 docs/migrations.md 的四步流程并参考 scripts/migrations 中现存脚本的 reviver 模式与测试写法即可快速上手。赞分享数据集开发工具【免费下载链接】browser-compat-dataBrowser compatibility data for Web technologies as displayed on MDN项目地址https://gitcode.com/gh_mirrors/br/browser-compat-data点击查看免费下载相关推荐browser-compat-data Issue 分诊实战指南从新 Issue 到可执行数据的六步检查流程browser compat data Issue 分诊实战指南从新 Issue 到可执行数据的六步检查流程 本文是面向 browser compat dat数据集开发工具FlutterFire数据迁移自动化脚本Firebase迁移脚本示例FlutterFire数据迁移自动化脚本Firebase迁移脚本示例 你是否在Flutter应用升级Firebase SDK时遇到过数据结构不兼容的问题是否后端移动开发ComfyUI深度解析构建模块化AI创作工作流的终极指南ComfyUI深度解析构建模块化AI创作工作流的终极指南 ComfyUI作为当前最强大的模块化AI创作引擎为专业创作者提供了前所未有的控制力和灵活性。不同于人工智能大模型媒体生成本地部署上一篇draw.io 桌面版三平台通用的免费画图工具一条命令批量导出 6 种格式下一篇抖音批量下载工具 douyin-downloader 完整实战指南从一条视频到千条素材只需 5 分钟创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考