DEV Community: tetsu

Lessons learned from my Chrome extension migration to Manifest V3

tetsu — Sat, 14 May 2022 17:18:41 +0000

This is a record of the Manifest V3 migration of Mouse Dictionary.

Background

What is Manifest V3?

Existing Chrome extensions will stop working in 2023, unless migrated to Manifest V3.

(Manifest V2 support timeline)

This is not the main topic here, so please refer to official documentation and existing articles.

Mouse Dictionary is an Manifest V2 extension released in 2018, so sooner or later it had to be migrated to V3.

Cross-browser issue

As of May 2022, Firefox does not yet support Manifest V3, so the Firefox version must remain V2. This means that cross-browser extensions need to support both V2 and V3, which is quite a hassle.

Mouse Dictionary has tried to maintain Firefox support while migrating the Chrome version to V3, so please refer to this page if you are in a similar situation.

Actual migration

There is an official migration guide available.
https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/

The following is a record of the actual mundane migration work.

Preparation 1: Eliminate eval

Manifest V3 has more restrictions on eval() and new Function().

Mouse Dictionary was using Hogan.js as its Mustache engine, but because it was using new Function() internally, it was an obstacle in the V3 migration process.

Therefore, I eliminated new Function() by moving from Hogan.js to mustache.js.

Hogan.js, mustache.js, and Handlebars were originally considered as candidates for the Mustache engine, and Hogan.js was the fastest for the Mouse Dictionary usage.

I verified that mustache.js is compatible and fast enough so that it's capable of being the extension's new Mustache engine.

Preparation 2: Build for each browser

If you want to migrate the Chrome version to V3 and keep the Firefox version, it is not possible to prepare a single manifest.json for all browsers. package at build time.

In the case of the Mouse Dictionary, the appropriate manifest.json is included in the package at build time.

Change code and configurations

View changes on GitHub

Code

chrome.browserAction -> chrome.action

In V3, chrome.browserAction needs to be changed to chrome.action. Conversely, in V2 (Firefox), there is no chrome.action and chrome.browserAction needs to be used. In order to keep it cross-browser, some kind of device is needed.

There are many ways to realize this, but since this is the only code where cross-browser compatibility was necessary, I simply used a webpack constant.

if (BROWSER === "CHROME") {
  chrome.action.onClicked.addListener((tab) => {
    chrome.scripting.executeScript({
      target: { tabId: tab.id },
      files: ["main.js"],
    });
  });
} else {
  chrome.browserAction.onClicked.addListener(() => {
    chrome.tabs.executeScript({
      file: ". /main.js",
    });
  });
}

By the way, the code below also works.

if (chrome.action) {
  chrome.action.onClicked.addListener((tab) => {
    chrome.scripting.executeScript({
      target: { tabId: tab.id },
      files: ["main.js"],
    });
  });
} else {
  chrome.browserAction.onClicked.addListener(() => {
    chrome.tabs.executeScript({
      file: ". /main.js",
    });
  });
}

The former is a bit more economical because unneeded processing disappears at build time.

chrome.extension -> chrome.runtime

Since both chrome.extension and chrome.runtime work in V2 (Firefox), I simply replaced them.

- const url = chrome.extension.getURL(fname);
+ const url = chrome.runtime.getURL(fname);

manifest.json

permissions

- "permissions": ["storage", "unlimitedStorage", "activeTab"],
+ "permissions": ["storage", "unlimitedStorage", "activeTab", "scripting"],

background

   "background": {
- "scripts": ["background.js"],
- "persistent": false
+ "service_worker": "background.js"
   },

commands

   "commands": {
- "_execute_browser_action": {
+ "_execute_action": {
       "description": "Activate the extension"
     },

web_accessible_resources

- "web_accessible_resources": ["data/*.json"]
+ "web_accessible_resources": [
+ {
+ "resources": ["data/rule.json", "data/dict*.json"],
+ "matches": ["<all_urls>"]
+ }
+ ]

Unresolved issues

Doesn't work on local files

Mouse Dictionary used to work on local HTML documents opened in Chrome, but it is no longer working after the V3 migration. I know the cause, web_accessible_resources does not work in tabs opened with file:///~, but I can't find any official information about it, so I don't know if this is an intended change in V3 or a bug in Chrome, so I am waiting and seeing.

(FYI)

Shortcut key settings behavior is strange

Mouse Dictionary can set shortcut keys, but the behavior is not quite stable after the migration to V3. It seems that shortcut keys are not reflected immediately after they are set, but are reflected after restarting Chrome. There is nothing that can be done on the extension developer side, so we are just waiting to see how it goes.

Impressions

This is only a case of Mouse Dictionary, but the amount of code changed was small. However, there is still little information on the web about the experience of Manifest V3 migration, so it is difficult to research, trial and error, and verify how to change the code to make it work as well as V2.

epo: Handy Unix epoch time converter in Rust

tetsu — Sun, 08 May 2022 06:17:47 +0000

epo

epo is a handy Unix time <-> date string converter that also taking multiple time zones into account. Written in Rust.

GitHub repository

$ epo 1648771200 1648771200+86400 greenwich
|      Epoch |                Greenwich |
| ---------- | ------------------------ |
| 1648771200 | 2022-04-01T00:00:00+0000 |
| 1648857600 | 2022-04-02T00:00:00+0000 |

Install

brew tap wtetsu/epo
brew install epo

Or download binaries

Usage

UNIX time → date string

Basically just specify Unix time and timezone.

$ epo 1648771200 greenwich
|      Epoch |                Greenwich |
| ---------- | ------------------------ |
| 1648771200 | 2022-04-01T00:00:00+0000 |

Multiple UNIX times x Multiple time zones.

$ epo 1648771200 1648771200+86400 "1648771200+86400*2" greenwich +0900 new_y
|      Epoch |                Greenwich |                    +0900 |         America/New_York |
| ---------- | ------------------------ | ------------------------ | ------------------------ |
| 1648771200 | 2022-04-01T00:00:00+0000 | 2022-04-01T09:00:00+0900 | 2022-03-31T20:00:00-0400 |
| 1648857600 | 2022-04-02T00:00:00+0000 | 2022-04-02T09:00:00+0900 | 2022-04-01T20:00:00-0400 |
| 1648944000 | 2022-04-03T00:00:00+0000 | 2022-04-03T09:00:00+0900 | 2022-04-02T20:00:00-0400 |

Options can be in any order. You can also write a formula: add 86400 to get one day later.

When specifying tz database names, it is OK to use forward matching (here "new_y" is assumed to be America/New_York).

You can also write JavaScript code (boa is embedded)

epo "range(10).map(i=>1647165300+i*60)" los_angeles phoenix

It prints a Markdown formatted table, so it can be pasted here as is.

Epoch	America/Los_Angeles	America/Phoenix
1647165300	2022-03-13T01:55:00-0800	2022-03-13T02:55:00-0700
1647165360	2022-03-13T01:56:00-0800	2022-03-13T02:56:00-0700
1647165420	2022-03-13T01:57:00-0800	2022-03-13T02:57:00-0700
1647165480	2022-03-13T01:58:00-0800	2022-03-13T02:58:00-0700
1647165540	2022-03-13T01:59:00-0800	2022-03-13T02:59:00-0700
1647165600	2022-03-13T03:00:00-0700	2022-03-13T03:00:00-0700
1647165660	2022-03-13T03:01:00-0700	2022-03-13T03:01:00-0700
1647165720	2022-03-13T03:02:00-0700	2022-03-13T03:02:00-0700
1647165780	2022-03-13T03:03:00-0700	2022-03-13T03:03:00-0700
1647165840	2022-03-13T03:04:00-0700	2022-03-13T03:04:00-0700

In the above table, you can see the moment when Los Angeles enters daylight saving time: -0800 becomes -0700, and suddenly it is 03:00. Incidentally, Phoenix is known as an area in the U.S. where daylight saving time is not adopted, and it remains at -0700 all the time.

Date string → UNIX time

It interprets ISO 8601 formats appropriately.

$ epo 2022-04-01 2022-05-01T12:30 2022-06-15T12:30:45 tokyo hawaii gmt
|                Date | Asia/Tokyo |  US/Hawaii |        GMT |
| ------------------- | ---------- | ---------- | ---------- |
| 2022-04-01T00:00:00 | 1648738800 | 1648807200 | 1648771200 |
| 2022-05-01T12:30:00 | 1651375800 | 1651444200 | 1651408200 |
| 2022-06-15T12:30:45 | 1655263845 | 1655332245 | 1655296245 |

👁️Accelerates your coding using Gaze

tetsu — Fri, 03 Dec 2021 17:09:14 +0000

Software development often forces us to manually run the same commands over and over.

👁️Gaze runs commands for you, right after you save a file.

It significantly helps you stay focused on writing code!

Gaze is designed as a CLI tool to streamline your coding process.

Easy to use, out-of-the-box experience
Super quick response time
Language- and editor-agnostic
Flexible configuration options
Useful advanced features
Multiplatform support (macOS, Windows, Linux)
Efficient parallel execution handling

👁️Installation

On macOS

brew install gaze

Windows/Linux: download binary https://github.com/wtetsu/gaze/releases

👁️How to use

Gaze is incredibly easy to use.

gaze .

Then, open your preferred editor in another terminal and start coding:

vi a.py

👁️More examples

Gaze at one file. You can just specify file names.

gaze a.py

Gaze doesn't require complicated file specification options. You can leverage familiar shell wildcards like *, **, and ?. No need to memorize Gaze-specific command-line options!

gaze "*.py"

Gaze at subdirectories. Runs a modified file.

gaze "src/**/*.rb"

Specify an arbitrary command by -c option.

gaze "src/**/*.js" -c "eslint {{file}}"

Kill the previous one before launching a new process. This is useful if you are writing a server.

gaze -r server.py

Kill an ongoing process after 1000(ms). This is useful if you love infinite loops.

gaze -t 1000 complicated.py

Specify multiple commands in quotations, separated by newlines.

gaze "*.cpp" -c "gcc {{file}} -o a.out
ls -l a.out
./a.out"

👁️Motivation

I frequently write Python scripts to automate tasks. I'd create a.py, write a few lines, and then run python a.py. Often, the result wasn't perfect, so I'd edit a.py again and re-run python a.py.

This cycle repeated endlessly...

I realized I was constantly switching between my editor and terminal, typing the same command over and over again. It was a huge waste of time and energy!

That's why I developed Gaze: to automate command execution and eliminate this repetitive, manual process.

Learn more at: https://github.com/wtetsu/gaze