DEV Community: Gokul Kathirvel

My Intro to Chrome Extension Development - A Series

Gokul Kathirvel — Tue, 10 Aug 2021 03:39:50 +0000

Originally published on gokatz.me

Building a chrome extension is definitely a fun process! Chrome extensions open a whole new set of doors to the web developers and users as well.

That is the reason I'm planning this to be a series of blogs explaining in-depth about the chrome extension ecosystem and the development, testing, and deployment process. This is the first part which explains what are chrome extensions and a brief about other browser ecosystems.

What are Chrome Extensions?

As per the official chrome extension development guide, the definition for a chrome extension would be:

Extensions are software programs, built on web technologies (such as HTML, CSS, and JavaScript) that enable users to customize the Chrome browsing experience.

This definition is self-explanatory, right? However, I would put it in a slightly different way:

Extensions are used to enhance the browsing experience using the customization feature enabled by the browsers via various APIs

These customization ranges from changing a content, look and feel inside a webpage, injecting a widget into the page and all the way to intercept the network request and change its behavior and content. The possibility is limitless.

A little history

The extension architecture we are using today is a modern take by the web browser vendors to extend the browse functionality. Before the current extension architecture, we had plugin architecture using API surfaces like NPAPI, etc., You might have heard about the recently depreacted Adobe flash plugiun for the browsers. This is a classic example of plugin software.

Due to various limitations and issues such as security (No Sandboxing), stability, etc. browser vendors decided to deprecate the plugin ecosystem and come up with the now existing, browser extension architecture built using the existing web technologies.

Is it worth our time?

We might have heard about/used extensions that are fun to use and concise in functionality. However, the possibility is not so concise and companies around the globe are making use of this technology to improve the product experience and drive a lot more customers towards their brand/site. For instance, for a business like password managers/vault-like, Zoho Vault (I worked here 😉), LastKeep, etc., browser extensions are not an optional one. They had to have an extension to work seamlessly and it drives a major part of the user experience and of course, in turn, revenue.

Hence, depending upon our use case/business model, the knowledge about chrome extensions and it's development might be crucial and of course, there is always fun tweaking the browser behavior, right? 😉

How to build one?

We've seen a brief intro about the extension and its ecosystem. Let's dive into the actual chrome extension development process. The chrome extension development history has seen a lot of phases and the process we are following today is a result of the refinement of those phases. In the modern era, we can develop a chrome extension by using the web technologies we are familiar with, HTML, CSS, and JavaScript with the help of a bunch of browser APIs exposed by Chrome to access the internals of the browser itself. These APIs are the ones that help us to build the enhanced experience.

A-lot-simplified architecture would be something like:

The Standard

The development story of the extension had been coupled to individual browser vendors. Each vendor devised their own way to develop and package an extension for their browser software. This causes a lot of roadblocks for developers to build their extensions across multiple browser vendors. To solve this and to make the development process close to today's web developers, initially, Mozilla joined hands with Microsoft and Opera to come up with the initial draft. The spec closely resembles the APIs devised by Chrome for their extensions.

Unfortunately, lately, the spec has had no traction and dormant for some time. Let's hope the work will be resumed in near future in this space 🤞

The spec draft can be found here: https://browserext.github.io/browserext/

Why Just Chrome?

As we can see, browser vendors are more keen to unify the extension development process so that the extension will work cross-browser. Then, it will be a natural question, then why should we just learn about Chrome extension and not a genetic development process.

The main reason is that the web extension spec has still a long way to rely on and they are heavily inspired by Chrome's API. So,

we are gonna focus on building chrome extension as the skills are transferable to any browser vendors
We are gonna learn how to port a chrome extension into other browsers at the end of this series as well.

So, stay tuned. We gonna explore a lot about chrome extensions and the relevant ecosystem. Until then, see you all 👋👋

Grammarly won't work in dev.to?

Gokul Kathirvel — Tue, 10 Aug 2021 03:35:12 +0000

I noticed that grammarly is enabled for the editor in dev.to? I'm not sure if this was intentional or any issue with my browser. Anyone facing this?

I'm using latest Firefox.

I'm back on track and you should too!

Gokul Kathirvel — Sun, 25 Jul 2021 07:13:47 +0000

[Image from From unsplash.com]

Hello again 👋

Hope you are doing safe and healthy. This pandemic has sure made a huge not-so-good effect on all of us. Let's hope that fades away 🙏

Now, to the matter! It has been more than two years since I blogged on this site. That's the longest break I have ever taken since I started writing. Besides that, my time on pet projects was also reduced considerably. I always had some excuse to skip writing, like, I don't have time, there is a deadline coming up, I don't have any ideas to share, the idea I'm having is not worth sharing, so on among others. Honestly, I prioritize other things over writing (Maybe, I'm lazy! 😅)

[Image from From giphy.com]

When I look back on my two years of "not writing" I can see that there was sufficient space for more innovation on my path as writing was one of the major drives that pushes me to innovate and upgrade myself. Also, writing helped me to refine my ideas a lot in the past, clears my mind, and improves my concentration. I'm missing that "me" time!

Now, I understand that this is the apt time to resume my blogging habit. I'm gonna set a realistic interval to publish a blog - which I have to decide soon! I'll keep this space updated on the same. If you are also like me, halted your blogging habit, perhaps you can resume too at the earliest. The longest the break, the hardest it will be to resume back! (from my experience 😉)

See you all in my next blog 👋

Is there any direct alternative to Docsify to use React component instead of Vue?

Gokul Kathirvel — Thu, 10 Dec 2020 03:52:57 +0000

I'm using Docsify to document a web component library. For that I need to render those UI components, pass data, attach events etc., For this purpose, I'm using Vue components inside .md files as Docsify support those.

Is there any plugin or other generators which does the same using React with the simplicity of Docsify (dropping in a script tag in an existig index.html will work seamlessly)?

Fun With forEach

Gokul Kathirvel — Thu, 06 Jun 2019 09:18:37 +0000

So, what's a forEach?

forEach is a little guy who iterates/loops through the array and executes the given callback for each element. It's more like the traditional for loop, but with a functional touch. A sample snippet would be like,

let colors = ['black', 'blue', 'red'];

colors.forEach((color) => {
    console.log(`${color} is a cool color`);
});

And the output will be:

black is a cool color
blue is a cool color
red is a cool color

So, as you can see, forEach will invoke the callback for each entry of the callee array. Yes, you might already know that what's fun with this?

What's the Fun in there? 👯‍♂️

We are gonna see some snippets that you might not encounter in real-time products/application and try to guess the result of those snippets (without peeking through the output 👀). That's where the real fun lies 😉

Snippet 1

let colors = ['black', 'blue', 'red'];

colors.forEach((color) => {
    colors.push('cyan');
    console.log(`${color} is a cool color`);
});

console.log(colors);

So, When I thought through this snippet, I predicted this would lead to an infinite loop. That's totally understandable, right? But, our little guy, forEach, will run the callback only for the exact number of times as that of the initial array length.

This is a little Twitter poll stating a snippet like this. Check this out. You are not alone 😛

// Detect dark theme var iframe = document.getElementById('tweet-1129378217226203136-385'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1129378217226203136&theme=dark" }

Here, the initial array length is 3 and the callback will be executed only for 3 times. However, the callback can mutate/change the array. But, the callbacks will not be executed for the later elements that are outside the bound (initial length).

So, the output will be:

black is a cool color
blue is a cool color
red is a cool color
[ 'black', 'blue', 'red', 'cyan', 'cyan', 'cyan' ]

Snippet 2

let colors = ['black', 'blue', 'red'];

colors.forEach((color, index) => {
    colors[index+1] = 'cyan';
    console.log(`${color} is a cool color`);
});

console.log(colors);

As per the rule that callback can mutate the array, the output for this snippet will be somewhat straight-forward. From the first run itself, we are changing the array value of the next index to cyan with this colors[index+1] = 'cyan' statement. So, the output will be:

black is a cool color
cyan is a cool color
cyan is a cool color
[ 'black', 'cyan', 'cyan', 'cyan' ]

As you might be noticed, There is an extra element in the resulting array and that's because, on the last run (index = 2), we are assigning the next index (index = 3) element's value as cyan and as said before, the callback will not be run for that last element we just pushed as it resides outside the initial array length.

Snippet 3

let colors = ['black', 'blue', 'red'];

colors.forEach((color, index) => {
    delete colors[index+1];
    console.log(`${color} is a cool color`);
});

console.log(colors);

Now, we delete items from the array. What do you think the output will be? What will be the placeholder for the deleted items? undefined? NULL? or something else?

On Quick skim, a common prediction for the loop would be,

black is a cool color
undefined is a cool color
undefined is a cool color

this is because, we know that callback will be called for the initial length of the array and here in this array, that's 3.

but, deleting the array element will make that space a hole and this forEach guy is pretty smart and will not run the callback for the holes in the array.

So, when the callback is executed for the first element (index = 0), it will delete the second element and the callback for the same will not be executed and the loop will be skipped to the third element. So the output will be:

black is a cool color
red is a cool color
[ 'black', empty, 'red' ] // empty is just the representation of holes in V8

Snippet 4

So, How an empty array will be treated?

let colors = new Array(3);

colors.forEach((color, index) => {
    colors[index] = 'cyan';
    console.log(`${colors[index]} is a cool color`);
});

console.log(colors);

Nothing changes, the empty array will be having all elements as holes. console.log(colors) will result in something like

[empty × 3]

So the callback will not be executed for any of the holes and the actual output of the entire snippet will also be:

[empty × 3]

Snippet 5

Another less used feature in forEach is that it can accept a second parameter, thisArg and if that's passed, the callback will be executed with the passed context. The following snippet is just for the demo you can find a more relevant example on MDN. I haven't used arrow function here as that will make this to be undefined.

class colorHandler {
  isFavorite(color) {
    return color === 'cyan';
  }
}

let colors = ['black', 'blue', 'red', 'cyan'];

colors.forEach(function(color, index) {
    console.log(this.isFavorite(color))
}, new colorHandler());

the output will be:

false
false
false
true

So...

Hope this was fun. That's all for our little guy. There might be a lot of other fun stuff about forEach. Kindly share it in the comments to surprise us. Let's see in some time with another array method/property in Fun With Arrays series.

And a fun fact: This title was inspired from the awesome (😉) show hosted by Sheldon and Amy in The Big Bang Theory series, named, Fun With Flags.

EmberJS in 2019

Gokul Kathirvel — Fri, 31 May 2019 18:00:35 +0000

This blog post is a result of "Call for Blog Posts" initiative by Ember.js team for curating 2019 roadmap.

Also, I hope my first try on writing an emoji-less article! :fingers-crossed: (This should not be counted as an emoji, technically)

This is the first time I'm participating in the Ember roadmap blog post series. I personally like Ember and it's abstractions to enable and increase productivity.

In order to write this blog, I curated a list of things WRT documentation and communication in the ecosystem that can be improved. On checking the docs and guides, I'm stunned that most of those points are already addressed in the Guides and API docs. That's excellent to know. Thanks to all the core teams and the contributors.

Below is a list of few things that I love to see in the core framework and surrounding ecosystems in the coming years.

1) Lightweight builds

One of the reasons Ember is not considered among modern frameworks (that's the bitter truth) is that we aim to build a full-fledged framework with all the batteries included and ended up as a fat baby. I personally love this nature of Ember as most of the web apps ended up adding these batteries at some point of development.

However, when a developer from other framework or a new JavaScript developer evaluates frameworks, the bundle size will be a predominant deciding factor. So, tree shaking the framework modules (and application code) until that's being used will have a great impact on the above-said evaluation. I love to see these such builds being the default one in future Ember apps.

There are cases where I had to leave behind Ember for this reason despite Ember outperforms most other popular frameworks like React or Vue WRT. rendering speed

2) Embroider

I personally think we were hanging too much with a specialized build tool that built around broccoli for a long time. Experimenting with existing popular toolkits like Webpack with Embroider is so cool and the features that other framework users are enjoying for a long time such as HMR, Code Splitting at various levels (route, component, etc.,) can be brought into the ember ecosystem with Embroider. I love to see embroider being the default built tool in 2019.

3) Docs around Ember CLI and Broccoli internals

Developing Addon that is not presentational is really a harder process in Ember. The actual API documentation for CLI is really not helpful to accomplish a task easily (TBH, that's impossible). I usually refer to other similar addons that utilize these hooks and learn from them in order to implement my logic. Since this involves pretty low-level stuff, proper documentation would be wonderful.

4) Error Communication

This is inspired from the Vue ecosystem. We are not great at communicating the errors to the developers. Once I hit a few issues, it's tough to debug them and at least it requires considerable knowledge of the framework to identify and rectify them.

When working with Vue, I feel the error communication is more elegant. In some cases, I just need to copy paste the suggested output from the console into my code to make it work. I can see that the error messages in Ember revamped constantly and it will be great if it's taken into account when building the roadmap for the upcoming year.

For a new developer, Googling the cause of the issue might be really overwhelming if the necessary context was not given and it might lead to churn.

5) Developer Onboarding

I must accept that the onboarding of a new developer becomes much easier compared to the earlier days. But there are few little bumps I've seen personally in the past years.

QueryParams

This might be a little thing but it's really not intuitive. I've seen in new developers while working with query params, that it is not obvious to them why we have to make an entry in different files (controller file and the corresponding route file) TBH, I personally cannot justify why that is being implemented in such a way.

Testing as a separate section in the tutorials

This might be an "Unpopular Opinion" but keeping the testing section separate in the tutorial might be a good option especially when a new developer tries out the framework for the first time. Usually, a new developer loves to see something on the screen as quickly as possible and most time I see many developers skipping this testing section and start over as after they are comfortable with the actual framework.

Component composition and best practices

Basic preaching of topics like "why we need components?" and "How a UI piece can be built using different component compositions" and maybe few prevailing anti-patterns would be beneficial. I accept most of these topics are heavily opinionated, but, it would be great if we could document at least the most acceptable one. Maybe in a section named, "Advanced Component Concepts" or something similar.

6) Ember CLI Presets or Project template

This is a little nice to have functionality. I personally like the way Vue uses it's CLI. We can manually choose the features that we are going to use in our project, like TS or JS, Class-based component or Classic Components, Need Service workers or not from the CLI itself and the supporting packages will be installed by the CLI for us. Then we can save this as a preset and can be used in future projects. In Ember, we use features json to modify these settings and it would be cool to have this integrated with the CLI service itself.

A awesome addon which aims to do a similar thing is ember-cli-create (like vue create)

This post was originally posted on my personal blog: https://gokatz.me/. You can also find articles on EmberJs, Chrome Extensions, etc., on the blog

Can we have an online gathering of Browser Extension developers

Gokul Kathirvel — Wed, 15 May 2019 07:21:21 +0000

Hello All Devs,

I have seen a lot of great articles on Browser Extensions (Chrome, Firefox, WebExt etc.,) on dev.to. I myself love building extensions and wrote a few articles on related topics. But, I guess we don't hang out much to discuss extension arch, design, and more related things. can we organize a small remote online event?

First Time Speaker (FTS) with few tips

Gokul Kathirvel — Sat, 11 May 2019 12:12:26 +0000

Cover by Edwin Andrade from https://unsplash.com

FTS: First Time Speaker. Fake abbreviation made by me 😉

How it started

I can definitely describe myself as an Introvert 😑 It's really hard (or I can say, impossible) for me to initiate a conversation in a group of new people, even today. I wanted to do something about this, pushing myself out of my comfort zone.

So, I decided to apply for the local tech meetups. While on the search, I found AwesomeConf which focuses on the Vue framework. The theme was, "No one shall be a passive attendee", means everyone has to speak at least for 5 or so minutes. I really like that as the theme seems to force me to speak 😜. So, I applied for this conference. A few days later, I got a DM from the organizer that my topic was selected to present.

Yay! Selected 🕺 Ouch! Selected 🥴

That was a mixed feeling. I was really happy that my proposal was selected 🤩 as well as I started to feel anxious about the stage, audience and literally everything 🤯. I really gave a lot of thought before committing to this. Finally, I replied that I'm glad to speak at the conference.

The Preparation Era

From that moment, I pour a lot (like a loooottt...) of time in preparing the content and slides. Initially, the content was okayish and I moved on to the preparation part. I'm not a native English speaker and my language fluency is not that much strong especially when it comes to public speaking. So, I started to prepare slide notes. I literally wrote every single line that I planned to talk (Beleive me, I even wrote down the greetings and Thank you note).

Snap from my original slide deck

It was about 20 slides and I finish writing extensive notes for all, fairly a week before the conference. Next comes the actual speaking practice. This was the toughest part 😬. First I started to read out the notes loud (locking myself inside my room) to practice the flow. One of my friends, Sivakumar advised me to record the practice talk using QuickTime player or any such tool and re-watch it for improvements. It actually helped me a lot. I recorded about 4 trails and each one helps me to tune my presenting flow. TBH, when looked into the recording, I was terrified the way I read out the points. It was like reciting a poem to my teacher repeating a lot of words again and again and used a lot of "Ahhmm" word between phrases. If I did not do this practice, I can't imagine how my actual talk would be 😆

I have done a mock presentation with my friend, Sivakumar, a couple of days before the actual talk. He pointed out some really helpful changes wrt the setup and to the actual flow. I incorporated the most. At that point, my slides were in good shape.

A Travel story

Before the conference day, I have to travel from Chennai to Bangalore, the venue of the conference. This was another challenge of its own. I don't travel much. Traveling to another city (State, to be precise) for this conference was really like out of my comfort zone and despite that, honestly, I enjoyed the journey. I stayed in a hotel, which I pre-booked earlier, for the night before the conf day. As this was the first try to speak in a meetup/conf in my whole life, I could not sleep that night. Rehearsed 2 times, organized my editor. (Yes, I was decided to do a live coding 😜), prepared my tees and jeans, repeatedly visiting the conference website (only to see my name in the speaker list 😃). It was a great feeling to see my name 😇

Finally gone bed at almost 3:00 AM with an alarm set at 6.30 AM. Managed to wake up at 7:00 AM. Did another rehearse, freshened up, had breakfast and ready to check out at 8:30 AM. Reached the venue at 9:00 AM.

Finally at the hall

As soon as I entered the conf hall, I was able to realize that my heartbeat rate was elevated. Managed to chose a seat at the center of the hall. As per the schedule, I was the second speaker. So, I decided to give another skim of my slides.

But, unfortunately (or maybe, fortunately) the first speaker was running late that morning and one of the organizers asked me if I'm okay to start first. I accepted without a second thought and I don't know how I did that till date 🙃

So, the first speaker of the conference! Went up to the stage and the rest was like magic. Even though I cannot claim the talk to be perfect, I managed to finish all the slides as well as the coding session right on time (20 minutes) with a decent flow.

The entire 20 minutes was a great experience. That gives me confidence in applying for future meetups and conferences. It proved to me that I can face a group of people and project an idea that I know. This was the much-needed tool in my toolkit.

I got the perk of being the first speaker of the day. I watched all the 15 talks (yes, 15 talks in a day) without any elevated heart rates 😛. As I mentioned, talking to new people was really tough for me. But, the co-speakers were really welcoming and they themselves initiated the conversation and I really like this about meetups and conferences. Got some really good friends at the end of the day.

So, How was the conference? Well...

Overall, the entire experience was great and that was really an "AwesomeConf" of 2019 for me. I have to thank the organizers, Rahul and Swapnil as well as the awesome sponsor, Meesho, for the wonderful venue and again awesome lunch 😋

NOTE: If anyone wants to speak and you are not doing that because you think you are an introvert and not comfortable with a new group of people, I urge every one of you to attend/speak at the local meetup and conferences. You will never regret your choice and you'll definitely thank me.

Tips from an FTS:

As I mentioned, these are some tips I can give from my experience being a Frist time speaker as well as from my friends who helped me preparing the talk:

Prepare the slides as soon as possible.
Practise your talk enough. If possible, record them and re-watch. That will definitely help you in a lot of ways.
Try to do mock presentations with your friends and collect feedback (again, Record)
If you are planning to do live coding session, set up the IDEs and servers (if any) beforehand. You cannot make your attendees wait till the server is up or your IDE indexes all your files.
If you are using a web browser, which you will most likely be, try to keep your browser clean without a lot of extensions or fancy themes, new tab settings. Those things might distract attendees.
Prepare and use snippets to do coding faster. You need not write every single statement in front of the attendees.
If possible, prepare GIFs or video of your coding session. If anything goes wrong on live coding, we have a Plan B.
Have the presenter note in few mediums: Mobile, hard copy, desktop, etc.
Have breakfast on the conference day.
Prepare your stay and travel (if any) before the conference date. This will keep your focus on the presentation and avoid unnecessary last-minute surprises. Services like Uber, OYO are really helpful.
Take a lot of pics on the conferences 😉
Above all, try to interact with the attendees and speakers. At my view, it's one of the core parts of meetups and conferences.

Thanks for reading through my experience. I hope the tips will be helpful. I'm so grateful that a few of my friends are more excited about this than me. Once again, thanks to everyone who helped me in this little but effective journey.

The actual title of my talk was "Ember and Vue: How they share values?" and planning for another blog with the actual talk content. So, stay tuned. You can find all the cool pictures taken at the conference here

You can find me on Twitter as _gokatz

Setup Tailwind@next in Vue CLI 3 project

Gokul Kathirvel — Tue, 07 May 2019 06:05:05 +0000

Setting up Tailwind is really an easier process consist of few simple steps. But, developers who are new to Webpack or common CSS configuration like PostCSS (like me) might feel it difficult to join all the parts. This post will help to set up and run tailwind with basic configuration in a Vue CLI 3 project.

Create a new Project

Create a new Vue project using Vue CLI 3 using any of your presets.

vue create my-app

Install Tailwind (@next)

# Using npm
npm install tailwindcss@next --save-dev

# Using Yarn
yarn add tailwindcss@next --dev

Load all the Tailwind defaults

Load tailwind defaults in a .css file. Create a new css file (say, src/assets/css/tailwind.css) and load the defaults

/* tailwind.css */

@tailwind preflight;
@tailwind components;
@tailwind utilities;

Import this css file inside main.js entry file.

// main.js

// other imports
import '@/assets/css/tailwind.css'

Configure PostCSS

Configur PostCSS to use tailwind styles

// postcss.config.js

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
  ]
}

Now restart the vue server and start working with Tailwind 🎉
Watch this series for more Tailwind and Vue related tips 😉

Automate the UI Testing of your chrome extension

Gokul Kathirvel — Mon, 22 Apr 2019 16:04:02 +0000

Building a chrome extension is definitely a fun process! Chrome extensions open a whole new set of doors to the web developers and users. However, testing those awesome extensions is not as straight forward as testing any conventional web application in some aspects. In this post, Let's walk together with the path of adding our first test case that ensures the best for our extensions.

Why automate on the first place

The manual testing process is one of the boring stuff in Software Engineering 😆 With the various aspects such as new install, extension update, permission update, extension downgrade/delete of the Chrome extension, the process got a lot trickier and bored. It's really easier to miss testing few aspects on every release. Thus, automating these boring stuff can ensure the proper working of our extension during every single release.

How testing can be done

We will be testing a chrome extension using Puppeteer and structure our tests with the mocha test runner. Also, we'll see how to automate this testing process in your CI/CD process using CircleCI. You can use any of your favorite test runner and CI/CD tool.

Let's install our dependencies first,

yarn add puppeteer mocha -D

npm i puppeteer mocha --dev

We can test our chrome extensions with the help of Puppeteer by mimicking the steps we would follow in our manual testing process.

Open Chrome Browser
Load the unpacked version of the extension (via chrome://extensions page - dev mode)
Open our extension popup/index page
Test the targeted features

Let's automate those steps one by one. For better understanding, Kindly test the script we are building at each step by running them (node test.js) then and there.

Step 1: Open Chrome Programmatically

As a first step, we need to control Chrome programmatically. That exactly where Puppeteer helps us. As per the docs, Puppeteer is a Node library which provides a high-level API to control headless (and full non-headless) Chrome. In our case, we need to boot Chrome in full form as extensions can load only in full form.

// test.js

const puppeteer = require('puppeteer');

let browser = await puppeteer.launch({
  headless: false, // extension are allowed only in head-full mode
});

On running the script (node test.js), The chromium build will be boot up with an empty page. Kill the node process to close the Chromium browser.

Step 2: Load Extensions

Next up, need to load our extension into chrome. Extensions can be load into the browser instance using --load-extension flag given by Puppeteer. Additionally, we need to disable all other extensions to prevent any unnecessary noise using --disable-extensions-except flag.

// test.js

const extensionPath = <path-to-your-extension>; // For instance, 'dist'

const browser = await puppeteer.launch({
    headless: false, // extension are allowed only in the head-full mode
    args: [
        `--disable-extensions-except=${extensionPath}`,
        `--load-extension=${extensionPath}`
    ]
});

On running this script, Chrome instance will be booted along with your extension. You can find your extension logo on the toolbar menu.

Step 3: Go to the extension popup page

Extension popup/index page will open when we click on the extension icon in the toolbar menu. The same page can be opened directly using the chrome-extension URL for the easier testing process. A normal extension page URL will be like chrome-extension://qwertyasdfgzxcvbniuqwiugiqwdv/index.html. This URL can be dissected into,

Extension Protocol (chrome-extension)
Extension ID (qwertyasdfgzxcvbniuqwiugiqwdv)
Popup/Index page path (index.html)

We need to construct this kind of URL for our extension in order to visit the page. Here the unknown part is the Extension ID. Thus, we need to know the arbitrary ID of our the extension generated by Chrome.

Know your extension ID: The Proper way

Chrome will assign a unique extension ID to every extension when loaded. This will be random every time we boot the extension on a new Chrome instance. However, a stable extension ID specific for our extension can be set by following the steps mentioned in this SO answer. This will be a bit long process but fool-proof. We can safely rely on the stable ID to test our extensions as the ID will not change when booted in various Chrome instance using Puppeteer.

Know your extension ID: The Background Script way

However, if our extension got background scripts, then the process would be a bit straight forward. We can detect the Extension ID programmatically.

When using background scripts, Chrome will create a target for the background script as soon as the extension gets loaded (Step 2). All the page targets managed by Chrome can be accessed by the targets method of the booted browser instance. using these targets, we can pull out our specific extension target with the help of title property (which will be our extension title given in the manifest.json). This target will contain the random extension ID assigned by Chrome during the current boot up.

// test.js

// This wait time is for background script to boot.
// This is completely an arbitrary one.
const dummyPage = await browser.newPage();
await dummyPage.waitFor(2000); // arbitrary wait time.

const extensionName = <name-of-your-extension> // For instance, 'GreetMe'

const targets = await browser.targets();
const extensionTarget = targets.find(({ _targetInfo }) => {
    return _targetInfo.title === extensionName && _targetInfo.type === 'background_page';
});

Once you fetch your extension target, we can extract the ID from the target URL. A sample background target url will be like, chrome-extension://qwertyasdfgzxcvbniuqwiugiqwdv/background.html. So, the extraction will be like:

const extensionUrl = extensionTarget._targetInfo.url || '';
const [,, extensionID] = extensionUrl.split('/');

We successfully got our extension ID (by either way) 💪

En Route to the Extension page 🚌

Now, let's go to our extension page. For this, we need to create a new browser page and load the appropriate extension popup URL.


// test.js

// This is the page mentioned in `default_popup` key of `manifest.json`
const extensionPopupHtml = 'index.html'

const extensionPage = await browser.newPage();
await extensionPage.goto(`chrome-extension://${extensionID}/${extensionPopupHtml}`);

At this point, running the test script will boot up a new Chrome instance and open a new Page with your extension popup HTML page content as a usual web page.

Step 4: Test the targeted features

We have successfully booted up our extension page. It's time for a 🖐

Now, let's pour our web app testing knowledge here. As every web application, end-to-end testing can be done using DOM querying and asserting for the proper value. The same can be applied here. DOM of our extension page can be queried using the $ (querySelector) and $$ (querySelectorAll) APIs provided by Puppeteer. You can use your preferred assertion library. In this example, I'm using the node's native assert package.

// test.js

const assert = require('assert');

const inputElement = await extensionPage.$('[data-test-input]');
assert.ok(inputElement, 'Input is not rendered');

Events can be triggered on the extension page using various event APIs provided by the Puppeteer.

await extensionPage.type('[data-test-input]', 'Gokul Kathirvel');
await extensionPage.click('[data-test-greet-button]');
const greetMessage  = await extensionPage.$eval('#greetMsg', element => element.textContent)
assert.equal(greetMessage, 'Hello, Gokul Kathirvel!', 'Greeting message is not shown');

NOTE: Puppeteer got a lot of useful APIs to control and extract useful information from Chrome.

Use test runners

In order to patch tests in a meaningful manner and to get good visual feedback and, we can use a test runner. In this example, I'm going to demonstrate how to use mocha to structure our tests.

// test.js

describe('Home Page', async function() {
  it('Greet Message', async function() {
    const inputElement = await extensionPage.$('[data-test-input]');
    assert.ok(inputElement, 'Input is not rendered');

    await extensionPage.type('[data-test-input]', 'Gokul Kathirvel');
    await extensionPage.click('[data-test-greet-button]');

    const greetMessage  = await extensionPage.$eval('#greetMsg', element => element.textContent)
    assert.equal(greetMessage, 'Hello, Gokul Kathirvel!', 'Greeting message is not shown');
  })
});

Joining all the pieces

Let's join all pieces to create a completely automated test suite for your extension.

// test.js

const puppeteer = require('puppeteer');
const assert = require('assert');

const extensionPath = 'src';
let extensionPage = null;
let browser = null;

describe('Extension UI Testing', function() {
  this.timeout(20000); // default is 2 seconds and that may not be enough to boot browsers and pages.
  before(async function() {
    await boot();
  });

  describe('Home Page', async function() {
    it('Greet Message', async function() {
      const inputElement = await extensionPage.$('[data-test-input]');
      assert.ok(inputElement, 'Input is not rendered');

      await extensionPage.type('[data-test-input]', 'Gokul Kathirvel');
      await extensionPage.click('[data-test-greet-button]');

      const greetMessage  = await extensionPage.$eval('#greetMsg', element => element.textContent)
      assert.equal(greetMessage, 'Hello, Gokul Kathirvel!', 'Greeting message is not shown');
    })
  });

  after(async function() {
    await browser.close();
  });
});

async function boot() {
  browser = await puppeteer.launch({
    headless: false, // extension are allowed only in head-full mode
    args: [
      `--disable-extensions-except=${extensionPath}`,
      `--load-extension=${extensionPath}`
    ]
  });

  const dummyPage = await browser.newPage();
  await dummyPage.waitFor(2000); // arbitrary wait time.

  const targets = await browser.targets();
  const extensionTarget = targets.find(({ _targetInfo }) => {
    return _targetInfo.title === 'GreetMe';
  });

  const extensionUrl = extensionTarget._targetInfo.url || '';
  const [,, extensionID] = extensionUrl.split('/');
  const extensionPopupHtml = 'index.html'

  extensionPage = await browser.newPage();
  await extensionPage.goto(`chrome-extension://${extensionID}/${extensionPopupHtml}`);
}

we can run this script by invoking the mocha command.

mocha test.js

let's create an npm script in package.json to map the mocha command,

"scripts": {
  "test": "mocha test.js"
}

It would invoke the test and output the test case status in the terminal.

$ yarn test
$ mocha test.js


  Extension UI Testing
    Home Page
      ✓ Greet Message (142ms)


  1 passing (5s)

Congrats, You made far to the end 🤝

We have done creating our first test suites that test our extension page. It's time to wire this up with a CI overflow. I'm using CircleCI for this demo. We can use any such services like TravisCI, AppVeyor, etc.,

Wiring up with CI

create a config file for CircleCI, .circleci/config.yml and load up a few boilerplate steps. We will be using an image called circleci/node:8.12.0-browsers as this image has chrome pre-installed and we need not install any further dependencies. If you are using any other services, find an appropriate image with browsers pre-built.

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:8.12.0-browsers

    working_directory: ~/repo

    steps:
      - checkout
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}

          # fall back to using the latest cache if no exact match is found
          - v1-dependencies-

      # Install your dependencies
      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      # build the extension if required
      # Run our test suite 
      - run: yarn test

OoOHoO... Congrats again. We just automated our test process successfully 🔥🔥 Try to automate your existing and future extension's testing process and be calm on your future releases. The sample extension along with their (working) tests has been hosted in GitHub. If you need any help, you can refer to the source code.

Hope you find this piece of writing useful. If so, I wrote about automating the chrome extension deployment in your CI/CD process in this blog post. Check out if you are manually deploying your extension. This may be the time to automate that too 😉

Automate your chrome extension deployment in minutes!

Gokul Kathirvel ・ Mar 27 '18

#chrome #extensions #webdev #javascript

That's all for today. Let's meet at another time with some other exciting stuff. Bye for Now. If you got any feedback or suggestion, please post in the comment. I would love to work on that.

Can I edit my old dev.to article to add a canonical URL to my recently setup personal blog?

Gokul Kathirvel — Tue, 26 Feb 2019 16:51:13 +0000

I recently set up my personal blogging site, https://blog.gokatz.me/ and I wonder if I can add a canonical url to my blog from dev.to or I should do the other way by adding canonical URL to dev.to from my blog.

Testing "install" and "update" flows in chrome extensions

Gokul Kathirvel — Sun, 20 Jan 2019 19:30:14 +0000

Originally posted in my personal blog : https://blog.gokatz.me

This is a very tiny post pointing out to an existing chrome app development guide about testing chrome extension with respect to install and update flows. These testing may become tricky because during the development stage we use Unpacked extensions. With this method, we may not get to test the actual install and update flows as the related event will not be fired.

For instance, it's hard to test the permission flow when using the unpacked extension. We might include new permission into our manifest and need to test before pushing into the web store.

There is a way to test such scenarios. We can pack the extension locally (into a .crx file) and install our actual extension from a local file (using .crx format of the extension). So that, the chrome will treat it as a normal install. Thus, we can test all the install as well as update workflows.

This section of the chrome extension development guide walk through the process of:

Creating a .crx file (extension source) and .pem file (private key) for your extension
Installing the .crx file into Chrome
Simulating the update process using the .pem file. If the extension is loaded without a .pem file, it will be acted as a new install and if we load with an existing .pem file, the loaded .crx file will be treated as an update to an existing extension (if exists)

This section will be focused on the permission part we saw as an example. Hope this helps in deploying your extension with confidence.

Bonus Note:

Always have a staging build for your extension such as a separate webstore extension visible only to testers. Publish new builds to the test extension before making it live. I bet it will save you from a ton of awkwardness. It helped me a lot 😉