自荐一下我写的 chrome 扩展开发模板

[YuTengjing]

有以下特点：

1. 基于 webpack + react + TypeScript。
2. 这也是个人觉得最大的特点：支持修改 content script 能自动重载扩展和刷新当前页面。这样当你在开发 content script 的时候不需要去扩展管理页面先重载一下扩展再刷新注入了 content script 的页面。
3. 整个项目都 TypeScript 化，包括 webpack 配置和 devServer，使用 ts 配置 webpack 减少你查阅文档和手残的可能
4. 支持 sass/less CSS 扩展语言，使用 mini-css-extract-plugin 插件将 CSS 分离成 content CSS Script。也就是说你只需要你编写的 content js script，然后导入对应 style 文件，就可以像下面这样配置 manifest.json:

"content_scripts": [
    {
        "matches": ["https://github.com/pulls"],
        "css": ["css/pulls.css"],
        "js": ["js/pulls.js"]
    }
]

1. 使用 eslint 和相关插件 lint TypeScript，babel 编译 TypeScript，fork-ts-checker-webpack-plugin 检查 TypeScript 类型。

   eslint 取代 tslint 已经是必然的趋势，相关插件也比较成熟了。

   使用 babel 编译 ts 的好处是可以使用各种现有的 babel 插件，例如你用了 antd 作为 UI 组件库的化可以使用 babel-plugin-import 配置按需导入，使用 babel-plugin-lodash 配置 lodash 的按需导入，但是如果用 ts-loader 就没法用了。

2. 由于 chrome 的限制，官方的 chrome 扩展 react devtools 并不能审查 chrome-extension:// 协议的页面如 options，popup 页面。所以需要使用独立的 react devtools，模板也对这一点进行了支持，并且配置了 react/react hooks 的 hot reload。

项目地址: awesome-chrome-extension-boilerplate

[zhw2590582]

自动刷新我一直用这个，或者你可以整合一下： https://github.com/xpl/crx-hotreload

[YuTengjing]

@zhw2590582 不需要整合，我设计的模板除了 content scripts 只能自动刷新扩展和当前页面，其它页面例如 options 和 popup, background 等页面直接支持完整的 webpack 热更新。

[orzorzorzorz]

在不变动包含 chrome.xxx 的原有代码的前提下，可以只热更新 popup 的代码吗？
调细节的时候得一遍遍重新加载然后点图标看 popup 的改动效果，如果只构建 popup 就会出现 chrome.xxx undefined 的错，两者都让人看在眼里，疼在蛋上。

[YuTengjing]

@orzorzorzorz #3 可以的，只有修改了 popup 用到的代码才会且只会触发 popup 弹窗页面热更新。
其实 popup 本质就是渲染一个 html 文件，你可以当成一个普通的 SPA 开发。

补充一点知识细节：在我的认知里，chrome 扩展 yej 就是一个包含 manifest.json 的金泰文件最后会被 chrome 扩展托管为一个静态文件服务器，协议就是 chrome://xxx。然后 popup 也就是点击图标后的弹窗本质上就是访问中国静态服务器上的一个 options.html 文件，我们知道现在前端的 SPA 本质上访问的也就是一个 index.html，所以开发 popup 页面和开发普通的 SPA 是没有很大的区别的。不过还是有一些细节上的问题，例如由于 CSP 的限制 chrome 扩展不能执行 eval，内联 js 代码，这个通过配置 manifest.json 的 content_security_policy 字段即可。还有就是我们知道前端路由一般有 BrowserRouter 和 HashRouter 等 Router，因为 BrowserRouter 需要访问的服务器将所有 HTML 页面定向到 Index.html，但是 chrome 托管扩展的静态服务器是没法编程控制它将所有的页面定向到 popup.html，而且也没意义，使用 HashRouter 则刚刚好，又不会因为 URL 带 hash 值比较丑（因为看不到），又实现了前端路由的功能。

[YuTengjing]

尴尬，前面的回复好多错别字，重新整理了下知识细节部分：
在我的认知里，chrome 扩展本质上就是一个包含 manifest.json 的文件夹，最后会被 chrome 托管为一个静态文件服务器，协议就是 chrome://。然后 popup 也就是点击图标后的弹窗本质上就是访问静态服务器上的一个 options.html 文件。我们知道现在前端的 SPA 本质上访问的也就是一个 index.html，所以开发 popup 页面和开发普通的 SPA 是没有很大的区别的，都可以充分利用 webpack 模块化和热更新。不过还是有一些细节上的问题，例如由于 CSP 的限制 chrome 扩展不能执行 eval，内联 js 代码，这个通过配置 manifest.json 的 content_security_policy 字段即可。还有就是我们知道前端路由一般有 BrowserRouter 和 HashRouter 等 Router，因为 BrowserRouter 需要访问的服务器将所有 HTML 页面定向到 index.html，但是 chrome 托管扩展的静态服务器是没法编程控制它将所有的页面定向到 popup.html，而且也没意义，因为托管的不止一个页面还有 options 等页面。使用 HashRouter 则刚刚好，又不会因为 URL 带 hash 值比较丑（因为看不到），又实现了前端路由的功能。

[YuTengjing]

写了一篇文章：[使用 webpack 构建 chrome 扩展的热更新问题]( https://lyreal666.com/%E4%BD%BF%E7%94%A8-webpack-%E6%9E%84%E5%BB%BA-chrome-%E6%89%A9%E5%B1%95%E7%9A%84%E7%83%AD%E6%9B%B4%E6%96%B0%E9%97%AE%E9%A2%98/)