企业官网建设流程全解析

Return YouTube Dislike 扩展开发贡献指南：从环境搭建、构建流程到提交 PR 的完整实战

【免费下载链接】return-youtube-dislikeChrome extension to return youtube dislikes项目地址: https://gitcode.com/gh_mirrors/re/return-youtube-dislike

导读

本篇文章以仓库根目录下的 CONTRIBUTINGgr.md（贡献指南希腊语版，与 CONTRIBUTING.md 英文版内容一致）为骨架，面向想要为 Return YouTube Dislike 开源扩展贡献代码的开发者。文章完整继承了原指南中的环境要求（Node/npm 版本）、依赖安装与两种构建模式（npm start与npm run build）、Issue 与功能请求提交流程、PR 验收标准，并结合仓库内的 package.json、webpack.config.js 与 Extensions/combined/manifest-chrome.json 等源码级证据，深入讲解构建产物bundled-content-script.js（即现在的ryd.content-script.js）是如何被编译、分发并注入 manifest 的。读完本文，你将掌握该扩展从零开始编译源码、调试开发、提交 Bug 修复与功能实现的完整链路。

一、贡献前的准备：仓库结构与核心产物

Return YouTube Dislike 是一个开源浏览器扩展，用于在 YouTube 网页端恢复显示点踩（dislike）数量。贡献者所做的任何改动，都会体现在扩展的下一个版本中（部分改动会同步到官方网站）。

在动手前，建议先了解仓库的关键目录：

• Extensions/combined/：扩展源码的聚合目录，包含ryd.content-script.js（内容脚本入口）、ryd.background.js（后台脚本）、popup.html/popup.js（弹窗界面）以及 src/ 下的模块化源码（如buttons.js、state.js、events.js、utils.js等）；
• Extensions/combined/manifest-chrome.json：Chrome 清单文件模板，构建时会自动注入版本号；
• Website/：基于 Nuxt.js 构建的官方网站源码（见 Website/package.json），是"网站贡献"类 PR 的落点；
• Extensions/UserScript/Return Youtube Dislike.user.js：面向其他浏览器的用户脚本版本。

原指南明确指出：要生成包含扩展大部分业务逻辑的bundled-content-script.js，必须先安装全部依赖。需要说明的是，随着仓库演进，这个构建产物在 webpack.config.js 中对应的入口文件现在名为ryd.content-script.js，它正是 manifest-chrome.json 中content_scripts.js数组所引用的文件。

二、环境要求：Node 与 npm 版本

根据原指南，搭建构建环境需要预先安装 Node.js 与 npm。指南给出的参考版本为：

版本说明：以上是贡献指南撰写时使用的版本，属于"参考而非强制"的推荐配置。当前仓库的 package.json 中engines字段未做硬性限制，但构建脚本依赖 webpack 5、Babel 7 等现代工具链，如果本机 Node 版本过旧，建议优先使用 LTS 版本或通过 nvm 切换版本后再执行构建。

同时，原指南要求代码格式化统一使用Prettier 的默认设置。仓库在 package.json 中内置了"prettier": { "printWidth": 120 }配置，并通过lint-staged（见 package.json）在提交时自动对暂存文件执行prettier --write --ignore-unknown，也就是说只要安装了依赖，保存与提交阶段就能自动完成格式化校验。

三、安装依赖与两种构建模式

3.1 安装依赖

在仓库根目录执行：

npm install

这一步会依据 package.json 安装运行时依赖（如country-code-lookup、echarts、topojson-client等，用于网站侧地图与统计功能）以及开发依赖（webpack、jest、prettier、husky 等）。

3.2 构建命令：npm start与npm run build

原指南给出了两条核心命令：

npm start # 创建构建文件，并启动一个文件监视器（watcher），在保存文件时热重载 # 或 npm run build # 一次性生成构建文件

需要特别指出的是：在当前版本的 package.json 中，npm start的行为已经演进为一条提示信息——它建议开发者改用以下两个脚本：

• npm run dev：等价于webpack --mode=development --watch，即开发模式 + 文件监视，保存时自动增量重编译（对应原指南中npm start的"热重载"语义）；
• npm run build：等价于webpack --mode=production，一次性生成生产构建产物（与原指南一致）。

也就是说，原指南中"npm start创建构建文件并热重载、npm run build一次性构建"的意图，如今分别由npm run dev与npm run build承接，语义完全对应。开发时若想获得"改完即生效"的体验，直接运行：

npm run dev

3.3 构建背后的实现：webpack 配置解析

构建流程由 webpack.config.js 驱动，理解它有助于你判断"改哪个文件、构建出什么"。核心要点如下：

1. 入口（entry）：构建入口共四个——ryd.content-script、ryd.background、popup、ryd.changelog，对应 Extensions/combined/ 下的同名.js文件；
2. 输出（output）：产物统一输出到Extensions/combined/dist目录；
3. 多目标分发（CopyPlugin）：构建完成后，通过 copy-webpack-plugin 将Extensions/combined复制为chrome、firefox、safari三个分发目录，并分别套用对应的 manifest 模板（manifest-chrome.json、manifest-firefox.json、manifest-safari.json）；
4. 清单变换（manifestTransform）：构建时会剥掉 manifest 模板中//开头的注释行，并把__RYD_VERSION__占位符替换为 package.json 中的真实版本号（见 webpack.config.js）；
5. 产物镜像（MirrorJsOutputsPlugin）：把编译出的.js文件同步复制到chrome、firefox、safari三个目标目录，保证各分发版本使用同一份逻辑。

从源码结构看，内容脚本的注入链路为：webpack 编译 Extensions/combined/ryd.content-script.js → 产出ryd.content-script.js→ 被 manifest-chrome.json 的content_scripts声明引用 → 在*://youtube.com/*、*://www.youtube.com/*、*://m.youtube.com/*页面（排除 YouTube Music）自动执行，并同时注入content-style.css样式。

四、验证构建结果：manifest 与测试

4.1 在 manifest 中核对产物

构建完成后，打开Extensions/combined/dist/chrome/manifest.json，应能看到content_scripts[0].js中引用了ryd.content-script.js，且version字段已被替换为真实版本号（模板中写作__RYD_VERSION__，见 manifest-chrome.json）。这与原指南"运行命令以创建bundled-content-script.js，该文件用于manifest.json"的说明一脉相承——产物文件名随版本演进，但"构建产物被 manifest 引用"的关系不变。

4.2 运行测试

仓库配有基于 Jest 的单元测试套件，配置见 jest.config.js，覆盖范围包括Extensions/combined/src/**/*.js与Extensions/combined/*.js（例如src/utils.spec.js、src/state.spec.js等）。提交 PR 前建议运行：

npm test

保证改动不破坏既有逻辑，这也是 CI 会执行的基础校验。

五、Issue：报告问题与解决问题

5.1 开启一个新 Issue

如果你在使用扩展时遇到问题，请先搜索，确认该问题尚未被报告过，避免重复。若确认是新的问题，再通过 Issue 表单创建（表单为推荐用法，非强制）。创建时应尽量描述清楚：

• 复现步骤与期望行为/实际行为；
• 浏览器类型与版本、扩展版本号；
• 出错页面（普通视频页、Shorts 短视频页等）与相关报错信息。

5.2 解决一个 Issue

如果你觉得某个 Issue 自己有能力修复，不要犹豫，直接开一个 PR 提交修复代码，并在 PR 描述中关联你所修复的 Issue 编号。修复类 PR 是仓库最欢迎的贡献类型之一，改动通常落在 Extensions/combined/src/ 下的模块文件中，例如：

• src/buttons.js：查找与渲染点赞/点踩按钮；
• src/state.js：扩展配置状态管理（如extConfig的读取）；
• src/events.js：监听 YouTube 页面导航事件与 MutationObserver 逻辑；
• src/utils.js：视频 ID 解析、选择器匹配、数字格式化等通用工具。

六、功能请求（Feature Request）

6.1 开启新功能请求

如果你对扩展有新想法，欢迎开启功能请求。同样地，先搜索以确保该功能尚未被提出；使用功能请求表单是推荐做法，但不强制。

6.2 实现一个功能请求

找到自己感兴趣且有能力实现的功能后，直接提交 PR，并在 PR 中明确提及你实现的是哪个功能请求。从源码结构看，新功能通常需要同时涉及：

1. 前端逻辑实现（修改或新增 src/ 下的模块，并在 ryd.content-script.js 入口中接入初始化调用）；
2. 若涉及用户偏好设置，还需要同步popup.html/popup.js的选项 UI；
3. 国际化文案（见 Extensions/combined/_locales/ 下各语言的messages.json）；
4. 配套单元测试（对应模块的*.spec.js文件）。

七、仓库接受哪些 PR？

原指南明确列出了四类会被接受的 PR：

• Issue 修复（Issue fixes）：修复已报告的缺陷；
• 功能实现（Feature implementation）：落地已提出的新功能请求；
• 拼写错误或更易读的措辞改进（Typos or better and easier words to use）：包括代码注释、文档与界面文案层面的润色；
• 网站贡献（Website contributions）：对 Website/ 目录下官方网站源码的改进，该目录基于 Nuxt.js 2 + Vuetify 构建（见 Website/package.json），页面代码位于 Website/pages/。

无论哪类 PR，都应遵守第三节提到的 Prettier 格式化规范，并尽量附带必要的单元测试。

八、快速上手总结

给新贡献者的最小可行路径如下：

# 1. 安装依赖 npm install # 2. 开发模式（保存即热重载，对应原指南 npm start 的语义） npm run dev # 3. 或一次性生产构建 npm run build # 4. 运行测试 npm test

构建产物位于Extensions/combined/dist/下的chrome、firefox、safari三个目录中，可加载到对应浏览器进行验证。之后即可按"搜索已有 Issue/功能请求 → 认领或新建 → 修改源码 → 本地验证 → 提交 PR 并关联编号"的流程贡献代码。所有贡献都将随下一个扩展版本发布，感谢每一位投入时间的贡献者。

【免费下载链接】return-youtube-dislikeChrome extension to return youtube dislikes项目地址: https://gitcode.com/gh_mirrors/re/return-youtube-dislike