DEV Community: Michel Canta

Should you use SvelteKit for your Chrome Extension?

Michel Canta — Sun, 10 Jul 2022 16:00:31 +0000

Is SvelteKit worth using or should people just use plain svelte or vanilla javascript?

This is the question that @yamessays asked me on my story on How to write a Chrome extension with SvelteKit.
I hadn't asked myself that, focusing instead on discovering if it was possible, how to make it work and seeing it in action. So after a couple days thinking and going back on my projects, I've come up with the following list of why you should and shouldn't use SvelteKit with Chrome Extensions and my take on which factors you should consider to make that decision.

Disclaimer

I am by no means a Svelte or Chrome Extension expert. I've written a few extensions in Vanilla JS and one with SvelteKit.
This analysis assumes that the extension you are writing uses Manifest V3.

Introduction

Svelte is a front end reactive web framework that allows developers to make highly reactive websites easily. It compiles your code into native js, html5 and css to make your websites quick and powerful.
Svelte comes with many useful tools, notably stores for state management. Stores are managed data that can be referenced, accessed and updated anywhere in your app.

Pros:

Reactivity: if you want to make your extension display a reactive popup this would be a great way to build it, make it interactive and reactive.
Stateful: if you need your extension to hold a state (persistent or not), Svelte's store is a great tool that helps you manage user credentials or preferences in your extension. Furthermore, the store allows you to easily send and receive data to your service worker and the tab on which your user is currently.
Speed: because all of your JS is already bundled and compiled into one file or multiple chunks, your extension is quick to load and display to the user.
Use JS libraries: because Svelte is able to bundle and compile all of your dependencies together it makes it extremely easy to use third party JS libraries. I used Supabase's library in my extension as I did on my website to handle user login.
Use CSS libraries framework: Same thing here, because of how Svelte processes and compiles your code, you can use CSS frameworks such as Tailwind directly on your extensions
Routes: you are able to use routes in your extension's popup to manage what you display to the user easily and manage your pages as your would a normal web app.
Single codebase: if your extension shares code with another of your products (e.g. your product's website), having a shared codebase for your components, layouts and styles may be extremely useful for your development needs.

Cons:

Your IDE will scream bloody murder if you try to use the chrome api's (as its not expecting those to be present).
You will still have to write custom JS to have a deeper interaction with the current tab/webpage (outside of what is offered through the chrome api).

Caveats:

You are unable to use Svelte on any injected files. This means that you cannot use it to control the DOM on the user's window, only the DOM that is provided for the popups/action/alerts from the Chrome extension context. Thus if your app has to interact or retrieve information from the webpage without the extension popup being open, you'll have to write custom JS to manipulate the DOM, maybe even use JQuery to help you in doing so. This could have been possible previously with Chrome's Manifest V2 but with the deprecation of V2 and stable rollout of V3, many more restrictions have been put in place.

Final Verdict

It all comes down to what you want to build. If your extension focuses on having a user interact with your service on any given web page and requires limited knowledge of the current tab/page, then yes, this is a good way to quickly build an extension and scale it.
If your extension attempts to improve the user's experience on a given webpage by adding features to it, you'll go back to writing vanilla JS and Svelte won't be of much use.
If you're injecting functionality that is only partly reliant on the current page (e.x. amazon price tracker) then Svelte and Svelte kit can be very useful but might be better suited as web-components to avoid style and javascript collisions.

Writing Chrome Extensions Using Svelte-Kit and Manifest v3

Michel Canta — Sun, 16 Jan 2022 08:12:35 +0000

Svelte-Kit has been an amazing tool to create great responsive and reactive websites. But with its roots as a compiler, I wondered how I could use it to create a Chrome Extension, and as it turns out… it's really simple.

Today, we're going to see how we can build a simple extension with Svelte-kit and use Chrome's Manifest V3 which will allow us to use promisified versions of many of the Chrome API's methods.

Note: this method can work with Manifest V2 as well

1. Setting Up Our Repo

We'll start with an empty repo where we will create the template svelte kit project.



npm init svelte@next my-extension
cd my-extension
npm install
npm run dev

We need to update the svelte.config.js file to rename our destination app directory by setting the appDir parameter to app (thank you @Matyanson for catching this in the comments).

We are going to replace the default index page that is created with the following code that will allow us to get the url of the current tab:

Note: We are using the Chrome api as other methods are blocked by the extension executer for safety reasons.

Update the body tag in the the app.html file to configure the max size of the extension popup as such:

Once updated we will create our manifest file in the /static folder. We will be using manifest V3 here as that is the latest from the Chrome team.



{
  "name": "My first Svelte Extension",
  "description": "A browser extension made with Svelte Kit",
  "version": "1.0.0",
  "manifest_version": 3,
  "permissions": [
    "activeTab"
  ],
  "action": {
    "default_title": "Svelte Extension",
    "default_icon": "favicon.png",
    "default_popup": "index.html"
  }
}

Now when we build our extension, the manifest file will be included in our build folder making it much easier and cleaner.

Finally we need to change our adapter to the sveltekit-adapter-chrome-extension as the usual @sveltekit/adapter-static creates an inline script that is blocked in Manifest V3 due to Content Security Policies (The same is true for Manifest V2 but you are able to define a Content Security Policy rule with a the sha256 of the script or a nonce, that bypasses it in Manifest V2).



npm install -D sveltekit-adapter-chrome-extension

We are then able to build our project running npm run build

2.Testing our Extension

Click on the extension icon in your chrome browser and then click on manage extensions

Make sure that developer mode is turned on (on the top right side of the page) then click on Load Unpacked.

Select your build folder from the file picker and open it. You should now see your extension on the page.

Make sure it is enabled and navigate to any page you want. Toggle the extension and press the button!

There you go! You've just made your first Chrome extension using Svelte Kit and Manifest v3!

Get detailed analytics and statistics from your Github Actions

Michel Canta — Wed, 08 Dec 2021 06:25:20 +0000

I love Github Actions, love building them, love using them and love helping others use them. But that last part is a bit difficult as Github does not provide a way to get analytical data on your action's usage by others such as: Who uses it? How often are they using it? Are there any errors when people try to use it? Do people try to use it and then decide not to due to some problems? Etc…

By getting the answers to these questions, Actions developers would be able to improve their actions to suit the needs of more people and make the experience for users better. So we decided to solve this problem and give developers the insights they need.

Getting Started
Start by creating you action, we'll be using the code from Github's tutorial on creating a new JS action you can find here.



const core = require('@actions/core');
const github = require('@actions/github');

try {
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput("time", time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

To start collecting data we install the gh-action-stats npm package:



npm install -S gh-action-stats

And then import it into our action and call the collectStats function as such:



const core = require('@actions/core');
const github = require('@actions/github');
const collectStats = require('gh-action-stats');

try {
  collectStats(); // You can collect stats at any point in the action.
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput("time", time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

By doing this you will start collecting statistics on your action once it is run in the context of a runner (does not currently support self hosted runners).

Collecting Run Statistics
The configuration above will work well but will leave out two key pieces of information: Errors and Duration of the run (how long did your action take to run).
To get these information we need to call the collectStats function differently:



const core = require('@actions/core');
const github = require('@actions/github');
const collectStats = require('gh-action-stats');

function main() {
  try {
    // `who-to-greet` input defined in action metadata file
    const nameToGreet = core.getInput('who-to-greet');
    console.log(`Hello ${nameToGreet}!`);
    const time = (new Date()).toTimeString();
    core.setOutput("time", time);
    // Get the JSON webhook payload for the event that triggered the workflow
    const payload = JSON.stringify(github.context.payload, undefined, 2)
    console.log(`The event payload: ${payload}`);
  } catch (error) {
    core.setFailed(error.message);
    // Rethrow the error so that it can be caught and logged 
    // by gh-action-stats 
    throw error; 
  }
}

collectStats(main);

By creating a main function, and passing it to the collectStats function, gh-action-stats will be able to execute your main function (even if it is async), collect all the previous statistics, catch errors and log them, and monitor run duration!

Accessing Data
Once you've configured your action to collect statistics, you will want to access your data. Go to actions.boringday.co and log-in using your Github account. Note, you will only be able to see the statistics for the actions you own (i.e. which you are the creator of). Once logged in and some run data has been collected you will have your dashboard with the list of the actions you own and the last time they were used.

Select the action you wish to visualize and the following dashboard will appear giving you insights on your action.

Notes
For the privacy of those using the actions, you will not be able to see the name of the repository if it is private to you, you will still be able to see the repo owner's name though if you want to contact them.
You can find the repository for the platform here: https://github.com/michmich112/gh-action-stats
And the npm package here: https://github.com/michmich112/gh-action-stats-js
You can visit our feature plans there and contributions are welcome!
This currently only works for JS Actions only, support for Docker images is on the way.