Return YouTube Dislike 贡献者开发指南：环境搭建、扩展构建与 Pull Request 提交流程
【免费下载链接】return-youtube-dislikeChrome extension to return youtube dislikes项目地址: https://gitcode.com/gh_mirrors/re/return-youtube-dislike
本文以 Return YouTube Dislike 仓库的 CONTRIBUTINGpl.md（波兰语贡献指南）为核心骨架，结合仓库中的package.json、webpack.config.js、各浏览器 manifest 清单与源码目录，系统讲解从零搭建本地开发环境、编译扩展、运行测试，到提交 Issue 与 Pull Request 的完整贡献流程。读完本文，你将掌握该开源扩展的构建原理（webpack 如何产出各浏览器分发包）、代码格式化规范，以及项目维护者接受的 PR 类型与协作惯例，能够直接上手参与开发。
环境准备：Node 与 npm 版本要求
在开始贡献之前，需要先在本地安装 Node.js 与 npm，因为扩展的“打包版本”（bundled version）必须通过 Node 工具链编译生成。贡献指南记录的搭建时使用版本为：
- node：12.18.4
- npm：6.14.6
需要说明的是，这两个版本是文档撰写时的搭建环境记录。当前仓库的package.json已升级到 webpack 5、jest 28、prettier 3 等较新的开发依赖，从源码结构看，这些工具链通常需要更高版本的 Node.js 才能正常运行，因此建议在本地安装较新的 LTS 版本 Node，并以node -v、npm -v确认环境可用。
除构建工具外，项目还要求代码格式化统一使用Prettier，且采用默认配置。仓库根目录 package.json 中已经内置了 Prettier 的全局配置（printWidth: 120），并通过 husky + lint-staged 在提交前自动对所有变更文件执行prettier --write --ignore-unknown，这意味着只要遵循仓库现有格式风格，提交阶段会自动完成格式化矫正。
构建流程：从依赖安装到产出打包文件
第一步：安装依赖
进入仓库根目录执行：
npm install该命令会根据根目录 package.json 安装全部依赖。其中dependencies包含扩展运行期用到的库（如country-code-lookup、echarts、topojson-client、world-atlas、us-atlas等，用于高级统计图表），devDependencies则包含构建与测试工具链（webpack、babel、jest、prettier、husky、lint-staged 等）。安装完成后即可进行编译。
第二步：编译构建
贡献指南给出了两种构建方式：
npm start // 创建构建文件并启动文件监听器，保存后热重载 // 或 npm run build // 一次性创建构建文件需要特别注意当前仓库的实际脚本映射。根目录 package.json 中的start脚本目前仅输出提示信息，真正承担“开发监听模式”与“生产构建”职责的是以下两个脚本：
npm run dev：执行webpack --mode=development --watch，以开发模式编译并持续监听文件变化，保存源码后自动重新打包，适合日常开发调试；npm run build：执行webpack --mode=production，一次性产出生产构建，适合发布前生成最终分发包。
因此，在当今版本中，开发调试请使用npm run dev，发布构建请使用npm run build。这与 Extensions/combined/readme.md 中“Compiling to Development / Compiling to Production”两节的说明一致。
构建产物与 webpack 配置解析
扩展的核心业务逻辑大部分位于bundled-content-script.js（即被各浏览器manifest.json引用的打包内容脚本）。当前版本中，webpack 实际打包的入口与产物由 webpack.config.js 定义：
const entries = ["ryd.content-script", "ryd.background", "popup", "ryd.changelog"];即四个入口分别对应：
ryd.content-script：注入 YouTube 页面、负责点赞/点踩数据渲染的内容脚本；ryd.background：后台脚本（Chrome 中作为 service worker，Firefox 中作为背景页）；popup：扩展弹窗界面；ryd.changelog：更新日志页面。
所有产物输出到Extensions/combined/dist目录，文件名保持[name].js结构（如ryd.content-script.js）。构建同时通过CopyPlugin将Extensions/combined下的静态资源分别复制为chrome、firefox、safari三个子目录，并执行两项关键转换：
- manifest 转换（
manifestTransform）：剔除 manifest 文件中的//注释后解析 JSON，并把manifestData.version替换为package.json中的版本号（process.env.npm_package_version，其中的-会被替换为.）； - i18n 转换（
i18nTransform）：将各语言messages.json中的__RYD_VERSION__占位符替换为真实版本号。
此外，MirrorJsOutputsPlugin会在编译完成后把打包出的 JS 文件镜像复制到 chrome、firefox、safari 三个子目录，确保每个浏览器分发包都包含最新的内容脚本与后台脚本。
各浏览器 manifest 的差异
构建产物中三个子目录分别使用对应的 manifest 清单，便于理解扩展在各平台的权限模型差异：
- Chrome（MV3）：manifest-chrome.json 采用
manifest_version: 3，后台使用service_worker: ryd.background.js，通过host_permissions声明对*.youtube.com与returnyoutubedislikeapi.com的访问，content_scripts匹配youtube.com域名并排除music.youtube.com； - Firefox（MV2）：manifest-firefox.json 采用
manifest_version: 2，后台使用脚本数组ryd.background.js，权限中直接包含activeTab、identity与两个主机权限，web_accessible_resources暴露menu-fixer.js； - Safari：manifest-safari.json 供 macOS Safari 转换使用，
package.json中提供了npm run build:safari脚本，可在生产构建后调用xcrun safari-web-extension-converter生成 Safari 工程（该命令依赖 macOS 的 Xcode 环境）。
在本地调试时，可直接在浏览器扩展管理页“加载已解压的扩展”，选择Extensions/combined/dist/chrome（Chrome）或Extensions/combined/dist/firefox（Firefox）目录即可。
测试与代码质量保障
仓库通过 jest.config.js 配置了 Jest 测试框架（resetMocks: true），测试覆盖范围包括Extensions/combined/src/**/*.js与Extensions/combined/*.js。运行全部测试使用：
npm test从源码目录结构看，测试文件与源码同目录放置，例如 Extensions/combined/src/utils.spec.js、Extensions/combined/src/bar.js 对应的功能均有.spec.js测试文件。若你新增或修改了核心逻辑（如点赞数格式化、按钮渲染、配置读取等），建议同步补充或更新对应的 spec 测试，并确保npm test全部通过后再提交。
代码风格方面，Prettier 承担统一格式化的职责，其默认配置以仓库根 package.json 的prettier字段为准。提交前 lint-staged 会自动格式化暂存文件，无需手工逐文件调整。
提交 Issue 的规范
如果使用扩展时遇到了问题，贡献指南要求遵循以下流程：
- 先搜索：在 Issues 列表中检索，确认该问题尚未被他人报告；
- 再提交：若确实无人报告，再新建 Issue。推荐使用 Issue 表单（form）填写，但并非强制。
如果你发现了一个自己有能力修复的 Issue，不必拘谨——直接打开一个带有修复内容的 Pull Request，并在 PR 描述中注明你所修复的 Issue，方便维护者关联追踪。
提交功能请求（Feature Request）的规范
功能请求与 Bug 报告的流程类似：
- 先搜索：提交前先检索仓库，确认该功能想法尚未被建议过；
- 再提交：若确属新想法，再打开功能请求，推荐使用功能表单填写，但非强制。
如果你找到了一个认为自己能够实现的功能想法，同样可以直接提交 PR，并在 PR 描述中说明你实现的具体功能，以便维护者评估。
项目接受哪些 Pull Request
贡献指南明确了维护者欢迎的 PR 类型，主要包括四类：
- Bug 修复（Issue fixes）：解决已报告问题的补丁；
- 功能实现（Feature implementation）：落实功能请求的新能力；
- 文字改进（Typos or better words）：修正拼写错误，或改用更准确、更易理解的措辞；
- 网站贡献（Website contributions）：对 Website 目录下的官方站点（Nuxt 项目，含多语言
_locales翻译文件与各页面 Vue 组件）的改进。
这意味着除了扩展本身的代码，官方文档与网站本地化（如Website/_locales/*.ts翻译文件、Docs/下的多语言 FAQ）同样欢迎贡献者参与。
开发提交前的自检清单
综合贡献指南与仓库实际配置，提交代码前建议逐项确认：
- 格式：代码已由 Prettier 默认配置格式化（lint-staged 会在
git commit阶段自动处理）； - 构建：
npm run build可成功产出Extensions/combined/dist下的 chrome、firefox、safari 分发包，且版本号正确注入 manifest 与messages.json； - 测试：
npm test全部通过，新增逻辑有对应 spec 覆盖； - PR 描述：明确说明修复的 Issue 编号或实现的功能，便于维护者审查与关联。
遵循上述流程，你的改动将随下一个版本的扩展（或官方站点）一同发布，这正是 Return YouTube Dislike 作为开源项目持续演进的协作方式。
【免费下载链接】return-youtube-dislikeChrome extension to return youtube dislikes项目地址: https://gitcode.com/gh_mirrors/re/return-youtube-dislike
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
