Integración de @teqfw/di y OpenAI SDK en una extensión de Chrome
Fecha de publicación: 2025-08-28Probé crear un prototipo de extensión de Chrome (MV3) para comprobar cómo funciona @teqfw/di en un entorno restringido y al conectar un SDK de terceros. De inmediato aparecieron tres áreas problemáticas: configuración del contenedor, restricciones de CSP y ejecución del OpenAI SDK en el navegador.
1. Rutas relativas
Problema: en la extensión no se pueden usar rutas absolutas al configurar el espacio de nombres en el contenedor. Las rutas absolutas dentro de una extensión de Chrome funcionan de forma distinta a un navegador normal o a Node.js.
- En Node.js, los módulos se cargan mediante
file://…
. - En el navegador — mediante
http(s)://…
. - En una extensión de Chrome — solo a través de
chrome-extension://<id>/…
.
Solución: al configurar el contenedor de objetos, usar siempre import.meta.url
para construir rutas relativas.
2. CSP y análisis de dependencias
La CSP en MV3 prohíbe por completo new Function
. En una versión anterior del contenedor se utilizaba este recurso para analizar dependencias, pero fue necesario pasar a una opción compatible sin código dinámico. Gracias a ello, el contenedor DI sigue funcionando bajo las estrictas limitaciones de las extensiones.
3. OpenAI SDK y limitaciones del navegador
El propio OpenAI SDK en el navegador requiere activar la opción dangerouslyAllowBrowser: true
. Es una protección contra la filtración accidental de la clave API. En mi prototipo, la clave se almacena en chrome.storage.local
en texto plano. Para una extensión eso es aceptable, pero aun así conviene añadir al menos una ligera ofuscación.
Ventajas del contenedor DI
El contenedor DI @teqfw/di integró los módulos ESM del OpenAI SDK como dependencias normales. Esto dio dos efectos inmediatos: el código se puede probar en Node.js y ejecutar en la extensión de Chrome sin cambios. El contenedor trabaja solo con los módulos ESM del SDK, lo cual coincide con el formato moderno.
Hace una semana lancé la primera versión estable de
@teqfw/di, pero ya han surgido nuevas solicitudes de mejora: se necesita un "modo seguro" sin new Function
. Este experimento demostró que incluso con las estrictas limitaciones de MV3 es posible construir una arquitectura flexible basada en
@teqfw/di.