Chrome runtime
The background.js service worker coordinates messages, authentication, caches, and tool calls.
Open source · MIT · Chrome Manifest V3
How Salesforce Org Compare works under the hood
A technical guide grounded in the public repository: architecture, browser-session authentication, local storage, Salesforce UI integration, and the contribution workflow.
View repository on GitHub
Technical overview
Key engineering decisions
The extension operates close to Salesforce while keeping working state in the browser.
Salesforce
Each org keeps its selected version; the project's current default API version is 63.0.
Working data
Preferences, aliases, comparisons, queries, and scripts live in chrome.storage.local.
Authentication
The session cookie is read when needed and is not persisted in extension storage.
Packaged interface
Monaco Editor, icons, and interface resources ship inside the extension.
Open source
The repository can be inspected, studied, and extended under the MIT license.
Architecture
From a user action to Salesforce
Local extension pages send actions to the service worker; it reuses the active session and calls official APIs with the user's permissions.
InterfacePopup · settings · app · viewersLocal extension pages and the Monaco editor.
OrchestrationManifest V3 service workerMessaging, org resolution, caching, and call control.
AccessActive browser sessionCookie read at runtime and never stored as a preference.
SalesforceREST · Tooling · Metadata APIsOperations are constrained by the connected user's permissions.
chrome.storage.localOrgs, preferences, queries, scripts, and cache.
sfInjectOptional DOM enhancements in Lightning and Setup.
Optional telemetryEU PostHog, opt-out, with no Salesforce record data.
Runtime
Operation flow
The same pattern supports a SOQL query, a metadata diff, or opening a log from Setup.
The user chooses an actionThe UI keeps the alias and org context.
The page sends a messageThe internal channel connects the tool to the service worker.
The session is resolvedThe extension finds the org and reads the session at runtime.
Salesforce is calledREST, Tooling, or Metadata API responds by permission and version.
The result is presentedA diff, table, log, or editor is rendered locally and may be cached.
Repository
Project structure
Responsibilities are separated across runtime, main UI, Salesforce integration, and shared resources.
Org authentication, message handlers, caches, and telemetry.
Main app: comparator, tools, and Monaco editor.
Org management, settings, and extension controls.
Optional content scripts and injectors for Lightning and Setup.
Shared APIs, internationalisation, and feature controls.
Unit tests with Vitest and end-to-end flows with Playwright.
sfInject
Explore Salesforce UI Integration →
Technical Salesforce UI integration
sfInject/content/bundle.js is generated. Its host checks the URL, frame, settings, and org or session requirements before mounting each injector; it also observes Lightning re-renders and removes controls when they no longer apply.
Tooling
Development environment
The repository uses Node.js, npm, Vitest, and Playwright. Installation rebuilds the Salesforce UI Integration bundle.
npm install
npm test
npm run test:e2e
npm run build:sf-inject
npm run minify:extension
npm run pack:chromeContent checked against the project's public README ↗.