gh,再输入一个查询词,就会跳到 GitHub 搜索结果页。一路上你会接好一份 manifest.json,并在后台 service worker 中处理输入。你还会练习每个项目都会遵循的开发循环(create → dev → build)。
你将构建什么
计划
让 GitHub 搜索像浏览器原生快捷方式一样快。扩展会保留关键字gh;当你输入 gh 加一段查询后,它会打开 GitHub 搜索结果页。
第 1 步:创建扩展
使用 Extension.js 的create 命令脚手架生成一个名为 github-search 的扩展。
默认模板是一个可以直接运行的 sidebar 起步模板,因此脚手架里已经包含
src/manifest.json 与 src/background.js。接下来的两步会替换这两个文件。
本教程里你写的所有内容都放在 src/ 下,因为只要存在 src/manifest.json,
Extension.js 就会优先使用它。
在用 Yarn?
yarn dlx 命令需要 Yarn 2 或更新版本。Yarn 1 没有
dlx,会以 “Command not found” 错误失败。在 Yarn 1 上,请改用
npm 标签页(npx)。在用 Deno? Deno 会非常激进地缓存 npm 包,包括 在
@latest
标签,因此 npm:extension@latest 可能一直解析到一个较旧的缓存版本。
如果脚手架生成或 dev 构建失败,而报出的错误在更新的版本里已经修复过
(例如 manifest.json references files that were not emitted to disk),请固定版本或刷新缓存:deno install 之后,先确认解析出的版本(extension 应当与最新发布版本一致),
再运行 deno task dev。create 会生成什么
create 会搭建一个完整的项目并初始化一个 git 仓库。默认模板生成这样的目录树:
tsconfig.json 和 extension-env.d.ts,用于带类型的扩展 API。
两个文件锚定了这个布局:
package.json标记项目根目录。特殊文件夹(pages/、scripts/、public/)和dist/输出都从那个目录解析,永远不从src/解析。manifest.json标记扩展源码。它可以放在根目录或src/里。当两处都存在时,src/manifest.json胜出。
第 2 步:创建 manifest 文件
每个扩展都从一份 manifest 文件开始。它定义元数据、权限以及运行时文件。基于 上面的计划,设置gh 快捷方式,并为用户事件添加一个 service worker。
打开脚手架创建的 src/manifest.json,把它的内容替换为:
omnibox.keyword:当你输入gh时,浏览器会触发一个事件。background.service_worker:监听你触发的事件。
第 3 步:创建后台 service worker
在浏览器扩展中,后台 service worker(一个独立于任何可见页面运行的脚本)负责处理浏览器事件。 在这个示例中,添加一个脚本,监听 Omnibox 输入,并把查询路由到 GitHub 搜索。 创建src/service_worker.js,并删除脚手架附带的 src/background.js,这样就不会再有别的文件占用 background 入口:
第 4 步:加载扩展
进入项目目录并安装依赖。create 只负责生成项目,并不会替你安装依赖,而 dev
脚本运行的是本地的 extension 可执行文件:
package.json 文件现在看起来是这样的,其中 extension 固定在你生成项目时所用的版本:
github-search 作为未打包扩展加载,并在终端中打印一条就绪横幅。Chrome 地址栏现在会把 gh 识别为关键字。
输入 gh 后空一格,再输入 extension.js,按下回车。新标签页将打开 https://github.com/search?q=extension.js&type=issues。
你现在已经有了一个可以在 GitHub 上搜索的可用浏览器扩展。
第 5 步:让它更好用
通过为 Omnibox 添加输入监听器,让搜索体验更上一层楼——直接在地址栏中显示建议。 更新service_worker.js,在用户输入时拉取 GitHub 建议并展示:
service_worker.js
下一步
- 使用 模板 创建另一个扩展。
- 用 Playwright 端到端测试 添加自动化检查。
- 随着扩展的成长,回顾 故障排查、安全清单 与 性能手册。

