后端音视频【免费下载链接】mediasoupCutting Edge WebRTC Video Conferencing项目地址https://gitcode.com/gh_mirrors/me/mediasoup点击查看免费下载mediasoup 是一个同时以 TypeScriptnode/src、Cworker和 Rustrust三种语言维护的 WebRTC SFU 项目其贡献流程围绕“改动必须跨语言同步、测试必须双端补齐、提交前必须通过全套自动化检查”三条铁律展开。阅读本文后你将掌握 mediasoup 的 Bug 报告渠道、PR 提交的完整验证命令npm run lint、npm run typescript:build、npm run test、npm run release:check与cargo fmt/clippy/test、它们各自在源码中的真实实现以及项目强制执行的注释编码规范能够以符合项目标准的方式向该仓库提交高质量代码。贡献前的约定ISC 许可证在向 mediasoup 提交任何代码之前需要先了解其许可条款项目采用 ISC License仓库根目录 LICENSE贡献者的贡献将被以 ISC 许可证授权。这一约定意味着你提交的代码会与项目保持同一许可供所有使用者自由分发与修改。报告 Bug 与获取支持的正确渠道mediasoup 将“问题追踪”与“技术支持”明确分流Bug 报告主要通过 GitHub 的 issue 追踪器进行遇到 bug 直接在 GitHub 上开 issue 即可。使用疑问与支持如果你对 mediasoup 有疑问或需要技术支持应当使用 mediasoup 的 Discourse 讨论组原文档提供https://mediasoup.discourse.group而不是开 issue——把 issue 留给真正可复现、可修复的缺陷是维护者希望的协作方式。崩溃类 Bug如果 mediasoup 发生了崩溃请在 issue 报告中尽量提供core dump核心转储文件。core dump 能让维护者直接定位到崩溃发生的二进制层面位置是排查 C worker 崩溃最有效的证据。这一点在源码层面也有对应印证worker 进程在没有收到必需的MEDIASOUP_VERSION环境变量时会以退出码 41 主动退出参见 npm-scripts.mjs 中对mediasoup-worker可执行性的自检逻辑说明维护者对 worker 二进制的健壮性检查是高度自动化的。Pull Request 流程三条必须遵守的规则当你在为 mediasoup 创建 Pull Request 时原文档明确规定了三条硬性要求TypeScript 与 Rust 双层同步在 TypeScript 文件node/src目录中做的改动/新增必须同步应用到 Rust 层rust目录反之亦然。这是因为 mediasoup 同时维护两套面向开发者的 API 绑定Node.js 与 Rust它们共享同一套mediasoup-workerC 核心任何 API 行为的不一致都会破坏跨语言一致性。测试必须双端补齐必须同时为Node.js 和 Rust添加对应的测试单元。从仓库结构看Node 侧测试位于 node/src/test如test-Worker.ts、test-Router.ts、test-WebRtcTransport.ts等Rust 侧单元测试位于各模块源码旁的tests.rs如 rust/src/router/consumer/tests.rsRust 集成测试则位于 rust/tests/integration。C 改动视情况补测试C 代码的改动/新增可能需要在worker/test目录下添加测试。该目录使用 Catch2 测试框架组织覆盖 BWE、ICE、RTCP、RTP、SCTP 等核心子系统参见 worker/test/src 下的TestNackGenerator.cpp、TestRateCalculator.cpp、TestSeqManager.cpp等。提交前必须运行的验证命令所有改动完成后需要运行以下命令来确认代码符合项目语法规范、没有破坏既有功能且测试全部通过命令作用npm run lint检查 TypeScript 与 C 的 lint 规则格式错误可通过npm run format自动修复npm run typescript:build将node/src下的 TypeScript 代码编译为node/lib下的 JavaScript 代码npm run test运行 JavaScript 与 C 测试单元npm run release:check一键执行上述全部步骤cargo fmt、cargo clippy、cargo test确保 Rust 一侧一切正常其中npm run release:check是提交 PR 前最值得使用的“一站式体检”。完整的npm脚本、invoke任务与cargo命令清单收录在 doc/Building.md本文后面会逐项展开。逐命令深入每个检查在源码里到底做了什么package.json中定义的 scripts 全部由 npm-scripts.mjs 中的同名任务实现package.json下面结合实现源码逐条拆解。npm run lintNode 与 worker 的双端静态检查lint依次调用lint:node与lint:workerpackage.json。lint:nodenpm-scripts.mjs实际执行了四件事用eslint-config-prettier校验 ESLint 配置与 Prettier 规则不冲突以--max-warnings 0严格模式运行 ESLint检查node/src、npm-scripts.mjs、rust-scripts.mjs、worker/scripts等路径并忽略自动生成的node/src/fbsFlatBuffers 生成代码用 Prettier 以--check模式校验node/src、doc、package.json、CONTRIBUTING.md等文件的格式运行 Knipknip --config knip.config.mjs检测未使用的依赖与导出。lint:workernpm-scripts.mjs通过 Python Invoke 调用worker目录下的 C lint 任务其底层是 worker/scripts/clang-scripts.mjs 中的lint()clang-scripts.mjs使用clang-format 23CLANG_FORMAT_VERSION 23见 clang-scripts.mjs对worker/src、worker/include、worker/test、worker/fuzzer、worker/mocks下的所有.cpp/.hpp执行--Werror --dry-run检查——注意版本是强校验的checkClangToolVersion()会解析--version输出并严格要求主版本号完全一致clang-scripts.mjs这也是原文档要求安装“特定版本 clang-format”的原因。如果你在本地没有对应版本的工具需要先安装原文档给出的安装方式具体版本号以 worker/scripts/clang-scripts.mjs 定义为准# macOS brew install clang-formatVERSION # Linux (Debian/Ubuntu 系) apt-get install clang-format-VERSIONnpm run format同理format:node用 Prettier 直接改写格式prettier --writeformat:worker则用 clang-format 以-i模式原地重写 C 文件clang-scripts.mjs。npm run typescript:buildTS 到 JS 的编译该命令调用buildTypescript({ force: true })npm-scripts.mjs实现为删除node/lib后执行tscnpm-scripts.mjs产出物即 package.json 中main与types指向的node/lib/index.js与node/lib/index.d.ts。也就是说node/lib是纯构建产物绝不手动编辑所有手写代码只存在于node/src。开发期间若想边改边编译可使用npm run typescript:watch它以tsc --watch模式监听node/src变化并持续输出到node/lib。npm run testNodeJest与 workerCatch2双层测试test依次执行test:node与test:workerpackage.jsontest:node实际命令为jest --silent false --detectOpenHandlesnpm-scripts.mjs。Jest 配置在 jest.config.mjstestRegex为node/src/test/test-.*\.ts即自动发现 node/src/test 目录下的全部test-*.ts文件同时忽略worker、rust、target等目录避免跨语言路径干扰。可通过--透传 Jest 参数做定向测试例如原文档给出的npm run test:node -- --testPathPatterns node/src/test/test-Worker.ts --testNamePattern createWorkertest:worker通过 Python Invoke 调用worker下的test任务npm-scripts.mjs构建并运行mediasoup-worker-test二进制它使用 Catch2 框架执行 worker/test 中的 C 测试单元。npm run release:checkPR 提交前的一键全检checkRelease()npm-scripts.mjs按序执行校验CHANGELOG.md中存在与 package.json 版本号对应的条目用于生成 GitHub Release 正文→ 安装依赖 → 强制重新生成 FlatBuffers 代码 → 强制编译 TypeScript → 构建 worker →lint:node→lint:worker→test:node→test:worker→npm pack --dry-run校验打包内容。在提交 PR 前运行npm run release:check等于把发布前的全部关卡在本地完整预演一遍。值得说明的是publishDryRun()npm-scripts.mjs为何用npm pack --dry-run而非npm publish --dry-run后者会联系 registry一旦package.json中的版本已发布就会报“You cannot publish over the previously published versions”而失效npm pack --dry-run同样会触发prepare脚本并精确组装 tarball却不写文件、不碰网络适合发布前验证files清单。Rust 侧检查cargo fmt、clippy、testRust 侧的检查命令集中在 rust-scripts.mjs 的lint()与test()rust-scripts.mjscargo fmt --all -- --check cargo clippy --all-targets -- -D warnings cargo test --verbose cargo test --release --verbose注意两点clippy以-D warnings将所有警告升级为错误即 Rust 代码不允许存在任何 clippy 警告测试同时跑 debug 与 release 两个 profile。Rust 侧的仓库结构印证了“测试双端补齐”的要求——每个模块源码旁都有同名tests.rs单元测试如 rust/src/router/webrtc_transport/tests.rs端到端集成测试则在 rust/tests/integration入口为main.rs覆盖worker、router、producer、webrtc_transport等场景并自带data/dtls-cert.pem、data/dtls-key.pem测试证书。发布相关为什么贡献者也要懂release流程原文档指向的 doc/Building.md 详细记载了npm run release x.y.z与npm run release:rust crate x.y.z的机制了解它有助于理解项目“tag 触发发布”的 CI 协作模型npm run release x.y.z要求传入 SEMVER 版本、位于主分支MAIN_BRANCH由版本号主段推导见 npm-scripts.mjs、工作树干净checkGitClean()检查git status --porcelainnpm-scripts.mjs。流程为先跑checkRelease()全检再用npm version x.y.z --no-git-tag-version升版本、把CHANGELOG.md的### NEXT标题替换为### x.y.z最后以release x.y.z [no-ci]消息提交、打 tag 并推送。推送的 tag 触发 GitHub Actions 的 NPM 发布工作流。[no-ci]是自定义标记带连字符用于让常规分支 CI 跳过这个纯版本提交同时不干扰 tag 触发的发布工作流。npm run release:rust crate x.y.z针对mediasoup、mediasoup-sys、mediasoup-types三个 crate定义于 rust-scripts.mjs。其中mediasoup发布走rust-x.y.ztag另外两个 crate 则通过提交消息中的[crate-publish]标记触发发布不打 tag。由于mediasoup依赖另外两个 crate多个 crate 需要发布时应先发布依赖mediasoup-types/mediasoup-sys最后发布mediasoup。MEDIASOUP_LOCAL_DEV环境变量Rust 开发时将其设为true可启用对已修改 C 源码的增量重编译方便本地调试 mediasoup见 doc/Building.md 的 Rust 一节。编码风格规范注释与行内文档在通过上述自动化检查之外项目还强制执行一些与编码风格相关的细节核心是TypeScript 与 C 中的注释规范JavaScript 与 C 源文件统一使用//行内注释注释必须以大写字母开头注释不能超过 80 列必要时拆成多行注释必须以句点结尾。反例与正例对比如下// Bad: 小写开头、无句点 // calculate foo based on bar value const foo bar / 2;// Good: 大写开头、以句点结尾 // Calculate foo based on bar value. const foo bar / 2;这条规则在仓库现有代码中有大量实际例证例如 node/src/Channel.ts 中的// Closed flag.、// Unix Socket instance for sending messages to the worker process.等注释均遵循“大写开头、句点结尾”的格式。此外为方法或函数添加行内文档时使用/** */语法/** * Calculates current score for foo and bar. */ function calculateScore(): number { // [...] }延伸参考完整的构建与任务清单如果需要在本地完整构建、运行 fuzzer、使用 Docker 镜像或执行 clang-tidy 等进阶操作请查阅 doc/Building.md。它系统整理了全部npm脚本typescript:watch、worker:build、worker:prebuild、flatc、coverage、tidy:worker等Python Invoke 任务定义于 worker/tasks.py可通过invoke --list查看包括invoke mediasoup-worker、invoke test、invoke test-asan-address、invoke test-asan-undefined、invoke fuzzer、invoke docker等以及作为其代理的worker/MakefileRust 增量编译MEDIASOUP_LOCAL_DEV与发布检查npm run release:rust:check说明clang-format与clang-tidy的安装指引版本由 worker/scripts/clang-scripts.mjs 定义其中 clang-tidy 版本为 21见 clang-scripts.mjs。小结总结来说向 mediasoup 提交高质量 PR 的关键动作是改动同时覆盖node/src与rust两个 API 层、为 Node 和 Rust 双侧补齐测试、C 改动在 worker/test 补 Catch2 测试、提交前运行npm run release:check或npm run lintnpm run typescript:buildnpm run test与cargo fmt/cargo clippy/cargo test并始终遵循“大写开头、80 列以内、句点结尾”的注释规范。这套流程从package.json的 scripts 定义、npm-scripts.mjs/rust-scripts.mjs的具体实现到 jest.config.mjs 的测试发现规则都有源码级的自动化支撑按规范执行即可确保你的贡献通过全部质量关卡。赞分享后端音视频【免费下载链接】mediasoupCutting Edge WebRTC Video Conferencing项目地址https://gitcode.com/gh_mirrors/me/mediasoup点击查看免费下载相关推荐深入 Nuitka 贡献指南PR 工作流、Git 钩子与质量检查全解析深入 Nuitka 贡献指南PR 工作流、Git 钩子与质量检查全解析 Nuitka 是一个用 Python 编写的 Python 编译器兼容 Python编译器开发工具NOFX 贡献者 PR 迁移实战指南同步 Rebase、代码质量检查与 Conventional Commits 标题规范NOFX 贡献者 PR 迁移实战指南同步 Rebase、代码质量检查与 Conventional Commits 标题规范 本文基于 NOFX 项目新的 PRAI Agent金融科技后端前端AionUi 贡献指南原子化 PR、Conventional Commit 与本地质量检查全流程AionUi 贡献指南原子化 PR、Conventional Commit 与本地质量检查全流程 本篇指南以 AionUi 仓库根目录的 CONTRIBUTI人工智能AI 应用AI Agent交互助手桌面应用移动开发上一篇scrcpy延迟35毫秒的手机投屏与遥控5分钟免费跑通下一篇pyWhat插件系统设计构建可扩展的识别框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深入 mediasoup 贡献指南：PR 全流程、三端同步与质量检查规范
后端音视频【免费下载链接】mediasoupCutting Edge WebRTC Video Conferencing项目地址https://gitcode.com/gh_mirrors/me/mediasoup点击查看免费下载mediasoup 是一个同时以 TypeScriptnode/src、Cworker和 Rustrust三种语言维护的 WebRTC SFU 项目其贡献流程围绕“改动必须跨语言同步、测试必须双端补齐、提交前必须通过全套自动化检查”三条铁律展开。阅读本文后你将掌握 mediasoup 的 Bug 报告渠道、PR 提交的完整验证命令npm run lint、npm run typescript:build、npm run test、npm run release:check与cargo fmt/clippy/test、它们各自在源码中的真实实现以及项目强制执行的注释编码规范能够以符合项目标准的方式向该仓库提交高质量代码。贡献前的约定ISC 许可证在向 mediasoup 提交任何代码之前需要先了解其许可条款项目采用 ISC License仓库根目录 LICENSE贡献者的贡献将被以 ISC 许可证授权。这一约定意味着你提交的代码会与项目保持同一许可供所有使用者自由分发与修改。报告 Bug 与获取支持的正确渠道mediasoup 将“问题追踪”与“技术支持”明确分流Bug 报告主要通过 GitHub 的 issue 追踪器进行遇到 bug 直接在 GitHub 上开 issue 即可。使用疑问与支持如果你对 mediasoup 有疑问或需要技术支持应当使用 mediasoup 的 Discourse 讨论组原文档提供https://mediasoup.discourse.group而不是开 issue——把 issue 留给真正可复现、可修复的缺陷是维护者希望的协作方式。崩溃类 Bug如果 mediasoup 发生了崩溃请在 issue 报告中尽量提供core dump核心转储文件。core dump 能让维护者直接定位到崩溃发生的二进制层面位置是排查 C worker 崩溃最有效的证据。这一点在源码层面也有对应印证worker 进程在没有收到必需的MEDIASOUP_VERSION环境变量时会以退出码 41 主动退出参见 npm-scripts.mjs 中对mediasoup-worker可执行性的自检逻辑说明维护者对 worker 二进制的健壮性检查是高度自动化的。Pull Request 流程三条必须遵守的规则当你在为 mediasoup 创建 Pull Request 时原文档明确规定了三条硬性要求TypeScript 与 Rust 双层同步在 TypeScript 文件node/src目录中做的改动/新增必须同步应用到 Rust 层rust目录反之亦然。这是因为 mediasoup 同时维护两套面向开发者的 API 绑定Node.js 与 Rust它们共享同一套mediasoup-workerC 核心任何 API 行为的不一致都会破坏跨语言一致性。测试必须双端补齐必须同时为Node.js 和 Rust添加对应的测试单元。从仓库结构看Node 侧测试位于 node/src/test如test-Worker.ts、test-Router.ts、test-WebRtcTransport.ts等Rust 侧单元测试位于各模块源码旁的tests.rs如 rust/src/router/consumer/tests.rsRust 集成测试则位于 rust/tests/integration。C 改动视情况补测试C 代码的改动/新增可能需要在worker/test目录下添加测试。该目录使用 Catch2 测试框架组织覆盖 BWE、ICE、RTCP、RTP、SCTP 等核心子系统参见 worker/test/src 下的TestNackGenerator.cpp、TestRateCalculator.cpp、TestSeqManager.cpp等。提交前必须运行的验证命令所有改动完成后需要运行以下命令来确认代码符合项目语法规范、没有破坏既有功能且测试全部通过命令作用npm run lint检查 TypeScript 与 C 的 lint 规则格式错误可通过npm run format自动修复npm run typescript:build将node/src下的 TypeScript 代码编译为node/lib下的 JavaScript 代码npm run test运行 JavaScript 与 C 测试单元npm run release:check一键执行上述全部步骤cargo fmt、cargo clippy、cargo test确保 Rust 一侧一切正常其中npm run release:check是提交 PR 前最值得使用的“一站式体检”。完整的npm脚本、invoke任务与cargo命令清单收录在 doc/Building.md本文后面会逐项展开。逐命令深入每个检查在源码里到底做了什么package.json中定义的 scripts 全部由 npm-scripts.mjs 中的同名任务实现package.json下面结合实现源码逐条拆解。npm run lintNode 与 worker 的双端静态检查lint依次调用lint:node与lint:workerpackage.json。lint:nodenpm-scripts.mjs实际执行了四件事用eslint-config-prettier校验 ESLint 配置与 Prettier 规则不冲突以--max-warnings 0严格模式运行 ESLint检查node/src、npm-scripts.mjs、rust-scripts.mjs、worker/scripts等路径并忽略自动生成的node/src/fbsFlatBuffers 生成代码用 Prettier 以--check模式校验node/src、doc、package.json、CONTRIBUTING.md等文件的格式运行 Knipknip --config knip.config.mjs检测未使用的依赖与导出。lint:workernpm-scripts.mjs通过 Python Invoke 调用worker目录下的 C lint 任务其底层是 worker/scripts/clang-scripts.mjs 中的lint()clang-scripts.mjs使用clang-format 23CLANG_FORMAT_VERSION 23见 clang-scripts.mjs对worker/src、worker/include、worker/test、worker/fuzzer、worker/mocks下的所有.cpp/.hpp执行--Werror --dry-run检查——注意版本是强校验的checkClangToolVersion()会解析--version输出并严格要求主版本号完全一致clang-scripts.mjs这也是原文档要求安装“特定版本 clang-format”的原因。如果你在本地没有对应版本的工具需要先安装原文档给出的安装方式具体版本号以 worker/scripts/clang-scripts.mjs 定义为准# macOS brew install clang-formatVERSION # Linux (Debian/Ubuntu 系) apt-get install clang-format-VERSIONnpm run format同理format:node用 Prettier 直接改写格式prettier --writeformat:worker则用 clang-format 以-i模式原地重写 C 文件clang-scripts.mjs。npm run typescript:buildTS 到 JS 的编译该命令调用buildTypescript({ force: true })npm-scripts.mjs实现为删除node/lib后执行tscnpm-scripts.mjs产出物即 package.json 中main与types指向的node/lib/index.js与node/lib/index.d.ts。也就是说node/lib是纯构建产物绝不手动编辑所有手写代码只存在于node/src。开发期间若想边改边编译可使用npm run typescript:watch它以tsc --watch模式监听node/src变化并持续输出到node/lib。npm run testNodeJest与 workerCatch2双层测试test依次执行test:node与test:workerpackage.jsontest:node实际命令为jest --silent false --detectOpenHandlesnpm-scripts.mjs。Jest 配置在 jest.config.mjstestRegex为node/src/test/test-.*\.ts即自动发现 node/src/test 目录下的全部test-*.ts文件同时忽略worker、rust、target等目录避免跨语言路径干扰。可通过--透传 Jest 参数做定向测试例如原文档给出的npm run test:node -- --testPathPatterns node/src/test/test-Worker.ts --testNamePattern createWorkertest:worker通过 Python Invoke 调用worker下的test任务npm-scripts.mjs构建并运行mediasoup-worker-test二进制它使用 Catch2 框架执行 worker/test 中的 C 测试单元。npm run release:checkPR 提交前的一键全检checkRelease()npm-scripts.mjs按序执行校验CHANGELOG.md中存在与 package.json 版本号对应的条目用于生成 GitHub Release 正文→ 安装依赖 → 强制重新生成 FlatBuffers 代码 → 强制编译 TypeScript → 构建 worker →lint:node→lint:worker→test:node→test:worker→npm pack --dry-run校验打包内容。在提交 PR 前运行npm run release:check等于把发布前的全部关卡在本地完整预演一遍。值得说明的是publishDryRun()npm-scripts.mjs为何用npm pack --dry-run而非npm publish --dry-run后者会联系 registry一旦package.json中的版本已发布就会报“You cannot publish over the previously published versions”而失效npm pack --dry-run同样会触发prepare脚本并精确组装 tarball却不写文件、不碰网络适合发布前验证files清单。Rust 侧检查cargo fmt、clippy、testRust 侧的检查命令集中在 rust-scripts.mjs 的lint()与test()rust-scripts.mjscargo fmt --all -- --check cargo clippy --all-targets -- -D warnings cargo test --verbose cargo test --release --verbose注意两点clippy以-D warnings将所有警告升级为错误即 Rust 代码不允许存在任何 clippy 警告测试同时跑 debug 与 release 两个 profile。Rust 侧的仓库结构印证了“测试双端补齐”的要求——每个模块源码旁都有同名tests.rs单元测试如 rust/src/router/webrtc_transport/tests.rs端到端集成测试则在 rust/tests/integration入口为main.rs覆盖worker、router、producer、webrtc_transport等场景并自带data/dtls-cert.pem、data/dtls-key.pem测试证书。发布相关为什么贡献者也要懂release流程原文档指向的 doc/Building.md 详细记载了npm run release x.y.z与npm run release:rust crate x.y.z的机制了解它有助于理解项目“tag 触发发布”的 CI 协作模型npm run release x.y.z要求传入 SEMVER 版本、位于主分支MAIN_BRANCH由版本号主段推导见 npm-scripts.mjs、工作树干净checkGitClean()检查git status --porcelainnpm-scripts.mjs。流程为先跑checkRelease()全检再用npm version x.y.z --no-git-tag-version升版本、把CHANGELOG.md的### NEXT标题替换为### x.y.z最后以release x.y.z [no-ci]消息提交、打 tag 并推送。推送的 tag 触发 GitHub Actions 的 NPM 发布工作流。[no-ci]是自定义标记带连字符用于让常规分支 CI 跳过这个纯版本提交同时不干扰 tag 触发的发布工作流。npm run release:rust crate x.y.z针对mediasoup、mediasoup-sys、mediasoup-types三个 crate定义于 rust-scripts.mjs。其中mediasoup发布走rust-x.y.ztag另外两个 crate 则通过提交消息中的[crate-publish]标记触发发布不打 tag。由于mediasoup依赖另外两个 crate多个 crate 需要发布时应先发布依赖mediasoup-types/mediasoup-sys最后发布mediasoup。MEDIASOUP_LOCAL_DEV环境变量Rust 开发时将其设为true可启用对已修改 C 源码的增量重编译方便本地调试 mediasoup见 doc/Building.md 的 Rust 一节。编码风格规范注释与行内文档在通过上述自动化检查之外项目还强制执行一些与编码风格相关的细节核心是TypeScript 与 C 中的注释规范JavaScript 与 C 源文件统一使用//行内注释注释必须以大写字母开头注释不能超过 80 列必要时拆成多行注释必须以句点结尾。反例与正例对比如下// Bad: 小写开头、无句点 // calculate foo based on bar value const foo bar / 2;// Good: 大写开头、以句点结尾 // Calculate foo based on bar value. const foo bar / 2;这条规则在仓库现有代码中有大量实际例证例如 node/src/Channel.ts 中的// Closed flag.、// Unix Socket instance for sending messages to the worker process.等注释均遵循“大写开头、句点结尾”的格式。此外为方法或函数添加行内文档时使用/** */语法/** * Calculates current score for foo and bar. */ function calculateScore(): number { // [...] }延伸参考完整的构建与任务清单如果需要在本地完整构建、运行 fuzzer、使用 Docker 镜像或执行 clang-tidy 等进阶操作请查阅 doc/Building.md。它系统整理了全部npm脚本typescript:watch、worker:build、worker:prebuild、flatc、coverage、tidy:worker等Python Invoke 任务定义于 worker/tasks.py可通过invoke --list查看包括invoke mediasoup-worker、invoke test、invoke test-asan-address、invoke test-asan-undefined、invoke fuzzer、invoke docker等以及作为其代理的worker/MakefileRust 增量编译MEDIASOUP_LOCAL_DEV与发布检查npm run release:rust:check说明clang-format与clang-tidy的安装指引版本由 worker/scripts/clang-scripts.mjs 定义其中 clang-tidy 版本为 21见 clang-scripts.mjs。小结总结来说向 mediasoup 提交高质量 PR 的关键动作是改动同时覆盖node/src与rust两个 API 层、为 Node 和 Rust 双侧补齐测试、C 改动在 worker/test 补 Catch2 测试、提交前运行npm run release:check或npm run lintnpm run typescript:buildnpm run test与cargo fmt/cargo clippy/cargo test并始终遵循“大写开头、80 列以内、句点结尾”的注释规范。这套流程从package.json的 scripts 定义、npm-scripts.mjs/rust-scripts.mjs的具体实现到 jest.config.mjs 的测试发现规则都有源码级的自动化支撑按规范执行即可确保你的贡献通过全部质量关卡。赞分享后端音视频【免费下载链接】mediasoupCutting Edge WebRTC Video Conferencing项目地址https://gitcode.com/gh_mirrors/me/mediasoup点击查看免费下载相关推荐深入 Nuitka 贡献指南PR 工作流、Git 钩子与质量检查全解析深入 Nuitka 贡献指南PR 工作流、Git 钩子与质量检查全解析 Nuitka 是一个用 Python 编写的 Python 编译器兼容 Python编译器开发工具NOFX 贡献者 PR 迁移实战指南同步 Rebase、代码质量检查与 Conventional Commits 标题规范NOFX 贡献者 PR 迁移实战指南同步 Rebase、代码质量检查与 Conventional Commits 标题规范 本文基于 NOFX 项目新的 PRAI Agent金融科技后端前端AionUi 贡献指南原子化 PR、Conventional Commit 与本地质量检查全流程AionUi 贡献指南原子化 PR、Conventional Commit 与本地质量检查全流程 本篇指南以 AionUi 仓库根目录的 CONTRIBUTI人工智能AI 应用AI Agent交互助手桌面应用移动开发上一篇scrcpy延迟35毫秒的手机投屏与遥控5分钟免费跑通下一篇pyWhat插件系统设计构建可扩展的识别框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
