Built using the svelte chrome extension boilerplate. Data stored in an airtable (for now). Plans to integrate this plugin with the larger open climate lab ecosystem. Initially developed during the first Yale OpenClimate Lab Collabathon. It draws inspiration from the Honey amazon shopping extension. The refined github extension source. See this guide for an overview.
Get up to speed with the slick frontend framework with Svelte docs, and the Chrome Extension reference will be useful.
A great way to get started is to check for good first issues on the tracker. Overall we try to plan and execute using the Kanban boards in github projects. We use gitflow and welcome pull requests from new collaborators of all backgrounds and affiliations.
- Check if your Node.js version is >= 6.
- Clone the repository.
- Install yarn.
- Run
yarn
. - Change the package's name and description on
package.json
. - Change the name of your extension on
src/manifest.json
. - Run
npm run start
- Load your extension on Chrome following:
- Access
chrome://extensions/
- Check
Developer mode
- Click on
Load unpacked extension
- Select the
build
folder.
- Access
- Have fun.
All your extension's development code must be placed in src
folder, including the extension manifest.
The boilerplate is already prepared to have a popup, a options page and a background page. You can easily customize this.
Each page has its own assets package defined. So, to code on popup you must start your code on src/js/popup.js
, for example.
Svelte components are under src/svelte/*.svelte
. The example popup component is provided at src/svelte/popup.svelte
. .svelte extension is used to distinguish components from static html files, required for an extension.
To make your workflow much more efficient this boilerplate uses the webpack server to development (started with npm start
) with auto reload feature that reloads the browser automatically every time that you save some file o your editor.
You can run the dev mode on other port if you want. Just specify the env var port
like this:
$ PORT=6002 npm start
Although this boilerplate uses the webpack dev server, it's also prepared to write all your bundles files on the disk at every code change, so you can point, on your extension manifest, to your bundles that you want to use as content scripts, but you need to exclude these entry points from hot reloading (why?). To do so you need to expose which entry points are content scripts on the webpack.config.js
using the chromeExtensionBoilerplate -> notHotReload
config. Look the example below.
Let's say that you want use the myContentScript
entry point as content script, so on your webpack.config.js
you will configure the entry point and exclude it from hot reloading, like this:
{
…
entry: {
myContentScript: "./src/js/myContentScript.js"
},
chromeExtensionBoilerplate: {
notHotReload: ["myContentScript"]
}
…
}
and on your src/manifest.json
:
{
"content_scripts": [
{
"matches": ["https://www.google.com/*"],
"js": ["myContentScript.bundle.js"]
}
]
}
After the development of your extension run the command
$ NODE_ENV=production npm run build
Now, the content of build
folder will be the extension ready to be submitted to the Chrome Web Store. Just take a look at the official guide to more infos about publishing.
If you are developing an extension that talks with some API you probably are using different keys for testing and production. Is a good practice you not commit your secret keys and expose to anyone that have access to the repository.
To this task this boilerplate import the file ./secrets.<THE-NODE_ENV>.js
on your modules through the module named as secrets
, so you can do things like this:
./secrets.development.js
export default { key: "123" };
./src/popup.js
import secrets from "secrets";
ApiCall({ key: secrets.key });
👉 The files with name secrets.*.js
already are ignored on the repository.
I would like to thank Samuel Simões for Chrome Extension Webpack Boilerplate, which was used as a base for this project. Some of the readme instructions were also reused.