Runtime de Chrome
El service worker de background.js coordina mensajes, autenticación, cachés y llamadas de herramientas.
Proyecto abierto · MIT · Chrome Manifest V3
Cómo funciona Salesforce Org Compare por dentro
Una guía técnica basada en el repositorio público: arquitectura, autenticación con la sesión del navegador, almacenamiento local, integración con Salesforce UI y flujo de contribución.
Ver repositorio en GitHub
Resumen técnico
Decisiones principales
La extensión opera cerca de Salesforce y mantiene el estado de trabajo en el navegador.
Salesforce
Cada org conserva su versión seleccionada; la versión predeterminada actual del proyecto es 63.0.
Datos de trabajo
Preferencias, aliases, comparaciones, consultas y scripts se guardan en chrome.storage.local.
Autenticación
La cookie de sesión se lee cuando hace falta y no se persiste en el almacenamiento de la extensión.
Interfaz empaquetada
Monaco Editor, iconos y recursos de interfaz viajan dentro de la extensión.
Código abierto
El repositorio puede inspeccionarse, estudiarse y ampliarse bajo licencia MIT.
Arquitectura
Del clic del usuario a Salesforce
Las páginas locales de la extensión envían acciones al service worker; este reutiliza la sesión activa y llama a las API oficiales con los permisos del usuario.
InterfazPopup · ajustes · aplicación · visoresPáginas locales de la extensión y editor Monaco.
OrquestaciónService worker MV3Mensajes, resolución de org, caché y control de llamadas.
AccesoSesión activa del navegadorCookie leída en ejecución; no se guarda como preferencia.
SalesforceREST · Tooling · Metadata APIsOperaciones limitadas por los permisos del usuario conectado.
chrome.storage.localOrgs, preferencias, consultas, scripts y caché.
sfInjectMejoras opcionales del DOM en Lightning y Setup.
Telemetría opcionalPostHog UE, desactivable y sin datos de registros Salesforce.
Runtime
Flujo de una operación
El mismo patrón sirve para una consulta SOQL, un diff de metadata o abrir un log desde Setup.
El usuario elige una acciónLa UI conserva el alias y el contexto de la org.
La página envía un mensajeEl canal interno comunica la herramienta con el service worker.
Se resuelve la sesiónLa extensión localiza la org y obtiene la sesión en tiempo de ejecución.
Se llama a SalesforceREST, Tooling o Metadata API responde según permisos y versión.
Se presenta el resultadoDiff, tabla, log o editor se renderiza localmente y puede quedar en caché.
Repositorio
Estructura del proyecto
Las responsabilidades están separadas entre runtime, interfaz principal, integración en Salesforce y recursos compartidos.
Autenticación de org, handlers de mensajes, cachés y telemetría.
Aplicación principal: comparador, herramientas y editor Monaco.
Alta y ordenación de orgs, ajustes y controles de la extensión.
Content scripts e injectores opcionales para Lightning y Setup.
APIs, internacionalización y controles compartidos.
Pruebas unitarias con Vitest y recorridos end-to-end con Playwright.
sfInject
Ver la integración con Salesforce UI →
Integración técnica con Salesforce UI
sfInject/content/bundle.js es un bundle generado. Su host valida URL, frame, ajustes y requisitos de org o sesión antes de montar cada injector; también observa los re-renderizados de Lightning y retira los controles cuando dejan de aplicar.
Tooling
Entorno de desarrollo
El repositorio usa Node.js, npm, Vitest y Playwright. La instalación reconstruye el bundle de integración con Salesforce UI.
npm install
npm test
npm run test:e2e
npm run build:sf-inject
npm run minify:extension
npm run pack:chromeContenido contrastado con el README público del proyecto ↗.