Showcase: devpro-toolkit — An All-in-One Developer Productivity Chrome Extension (Manifest V3)

Open-source showcase · github.com/Shivay00001/devpro-toolkit

TL;DR: devpro-toolkit is an all-in-one developer productivity Chrome extension built on Manifest V3: one popup housing a tab manager, a JSON viewer, a REST API client, a dark-mode injector, a focus mode with site blocking and Pomodoro timers, and security inspection tools — wired together by a service worker message router with settings persisted in chrome.storage. I read the manifest, the service worker, and the modules: this is a genuinely working extension with an unusually honest README that documents its own limits. Status: working — load-unpacked and usable today, not yet published to the Chrome Web Store.

1. What it is

The repo is a complete MV3 extension: manifest.json (valid JSON, version 1.0.0), a 23 KB popup/popup.js hub with its own CSS/HTML, six feature modules under modules/, a background service worker, content scripts, an options page, a blocked-page for focus mode, icons in four sizes, a lib/storage.js persistence layer — and a package.sh that zips it all for the Chrome Web Store. The six tools:

• Tab Manager (modules/tab-manager.js) — save named tab sessions, restore them later (optionally closing current tabs), and collapse all open tabs into a list.
• JSON Viewer (modules/json-viewer.js) — pretty-print and format JSON from the popup.
• REST Client (modules/rest-client.js) — a request builder: method, URL, headers, body; shows status, timing, response size, and headers; keeps a request history in chrome.storage.
• Dark Mode (modules/dark-mode.js + content/dark-mode.css) — force dark styling on pages via CSS injected by a content script.
• Focus Mode (modules/focus-mode.js) — a blocklist of distracting URLs; the service worker redirects blocked tabs to blocked/blocked.html; Pomodoro sessions run on chrome.alarms with a completion notification.
• Security Tools (modules/security.js) — client-side helpers including header inspection on the active tab.

2. The problem it solves

Developers accumulate single-purpose extensions: one for JSON formatting, one for tab management, one for dark mode, a standalone REST client, a focus blocker. Each one is another icon, another permission set, another abandoned-by-its-author risk, another thing to audit. The "all-in-one toolkit" pattern consolidates the daily-driver utilities into one codebase you can actually read — the entire extension is small enough to audit in an evening, which is the real security story for browser extensions (where the permission model makes "just install it" genuinely risky).

3. How it works — architecture

The extension follows the standard MV3 shape, executed cleanly:

• Manifest as contract. manifest.json declares MV3, the popup action, permissions (tabs, storage, activeTab, scripting, alarms, notifications), <all_urls> host permissions, the service worker, the options page, and a content script that injects dark-mode.css + content.js at document_start on all URLs.
• Service worker as router. background/service-worker.js does three jobs: (1) a tabs.onUpdated listener checks every loading tab against the focus blocklist and redirects matches to the blocked page; (2) an alarms.onAlarm listener ends Pomodoro sessions and fires the "Focus Session Complete!" notification; (3) a runtime.onMessage router dispatching fourteen message types (GET_DARK_MODE, TOGGLE_DARK_MODE, START_FOCUS/END_FOCUS, ANALYZE_SECURITY, SAVE_SESSION/GET_SESSIONS/RESTORE_SESSION/DELETE_SESSION, COLLAPSE_TABS, …) to the right module, keeping the async channel open with return true. It even attempts an auto-save of the tab session on suspend — with optional chaining and a "best effort" comment, which is the honest way to write that.
• Popup as hub. The popup is the control surface: it sends messages to the service worker and renders results, so the popup itself stays thin while the modules hold the logic.
• Storage as memory. lib/storage.js abstracts chrome.storage for settings and REST history, so preferences survive browser restarts and sync.

The REST client module is representative of the code quality: sendRequest times the request with performance.now(), parses JSON vs. text by content-type, captures status/headers/body/size, color-codes statuses (2xx success, 3xx warning, else danger), and unshifts every request into a persisted history. Header parsing helpers (parseHeaders/formatHeaders) handle the textarea-to-object round trip. It's a small Postman, in the browser, without an account.

3b. Two modules under the microscope

Focus mode is the most architecturally complete feature. The blocklist check runs in the service worker's tabs.onUpdated listener — every tab that starts loading gets its URL tested against the list, and matches are redirected to blocked/blocked.html before the page renders. Pomodoro sessions use chrome.alarms (the MV3-correct timer API, since service workers can't rely on setTimeout surviving suspension), and session end fires a native notification. It's a small state machine — idle → focusing → blocked-or-complete — implemented across the worker and the module with message passing, which is exactly how MV3 wants you to build it.

The tab manager solves a real daily pain: research sessions with 40 tabs open. SAVE_SESSION snapshots the current window's tabs by name into chrome.storage; RESTORE_SESSION reopens them, optionally closing what's currently open; COLLAPSE_TABS condenses everything into a list you can triage. Combined with the on-suspend auto-save ("best effort," with the honest comment that suspension timing isn't guaranteed), it means a browser crash costs you a session restore, not a morning of reconstruction.

Both modules share the codebase's best trait: they do one thing, they message the worker to do it, and the popup only renders. That separation is what makes the whole extension readable — and readability is the security story for anything you install unpacked.

4. The README's honesty section — worth highlighting

Most extension repos oversell. This README has a "Status & limits" section that does the opposite, and every claim in it checks out against the code I read:

• The premium module is a client-side placeholder — usage tracking and an upgrade modal exist, but there is no payment backend. The README says so outright instead of implying a SaaS.
• <all_urls> is flagged as too broad — the README itself recommends narrowing it or moving features behind activeTab before publishing. Correct advice; the dark-mode injector and REST client are the reasons it needs the broad permission today.
• Not published; load unpacked only — stated plainly, with the two-step install instructions.
• All JS passes node --check, manifest is valid JSON, referenced files present — verifiable hygiene claims, the kind a reviewer can confirm in minutes.

That candor is a feature. For a browser extension — software that runs with your cookies and your tabs — "here's exactly what it does and doesn't do" is the trust model.

5. How to run it

# 1. Open chrome://extensions, enable Developer mode
# 2. Click "Load unpacked", select this folder
# 3. The ⚡ icon opens the popup

To package for the Chrome Web Store or sideloading:

./package.sh   # creates devpro-toolkit.zip

The options page (options/options.html) holds the settings; the popup is the daily interface. No build step, no dependencies — it's plain JS, HTML, and CSS.

6. Honest status: what works, what to know

Working. All six modules are implemented, the service worker routing covers every popup action, persistence works through chrome.storage, and the packaging script produces a shippable zip. The repo even commits a built devpro-toolkit.zip.

Know before you install:

• Broad host permission: <all_urls> means the extension can read and modify data on every site you visit. That's how the dark-mode injector and content script work — but it's the maximum-privilege posture, and you should install it with eyes open (or narrow the permission yourself, per the README's own advice).
• Premium is cosmetic: the upgrade flow goes nowhere — no payment backend exists. Treat "Premium" as a UI mock, not a product tier.
• Unpublished: no Chrome Web Store listing means no Google review, no auto-updates — you sideload and update manually.
• Service-worker importScripts: the worker pulls in four modules via importScripts — fine, but note the popup's rest-client.js and json-viewer.js aren't in the worker's scope, so those run popup-side only.

7. Roadmap — toward a shippable 1.0

1. Permission narrowing — move dark-mode injection behind activeTab/user gesture and drop <all_urls>; this is the single biggest trust upgrade and the README already points at it.
2. Decide premium's fate — either wire a real payment backend or remove the upgrade modal; a dead paywall in a published extension erodes trust.
3. Chrome Web Store listing — publish with a real privacy policy (it touches browsing data), screenshots, and the permission justifications the store review will demand.
4. Session sync — tab sessions in chrome.storage.sync so they follow the developer across machines.
5. REST client depth — environments/variables, saved collections, and request chaining would take it from "handy" to "Postman replacement for quick calls."

Frequently asked questions

The bottom line

devpro-toolkit is six genuinely useful developer utilities in one auditable MV3 extension, with the rare virtue of a README that tells you exactly where the bodies are buried (cosmetic premium, broad permissions, unpublished). If you live in Chrome DevTools-adjacent workflows and you'd rather read 40 KB of plain JavaScript than trust another black-box extension with your tabs, this is worth the unpacked install — and a solid base for anyone learning how real Manifest V3 extensions are structured.

Source: github.com/Shivay00001/devpro-toolkit — MIT licensed. Verified by reading manifest.json, background/service-worker.js, modules/rest-client.js, modules/focus-mode.js, modules/security.js, and the README on the main branch.