Интеграция @teqfw/di и OpenAI SDK в расширении Chrome

Дата публикации: 2025-08-28

Попробовал собрать прототип браузерного расширения Chrome (MV3), чтобы проверить, как будет работать @teqfw/di в условиях ограниченной среды и при подключении стороннего SDK. Сразу проявились три области проблем: настройка контейнера объектов, ограничения CSP и запуск OpenAI SDK в браузере.

1. Относительные пути

Проблема: в расширении нельзя использовать абсолютные пути при конфигурации пространства имён в контейнере. Абсолютные пути внутри Chrome Extension работают иначе, чем в обычном браузере или Node.js.

Решение: при конфигурировании контейнера объектов всегда использовать import.meta.url для построения относительных путей.

2. CSP и парсинг зависимостей

CSP в MV3 полностью запрещает new Function. В ранней версии контейнера этот приём применялся для разбора зависимостей, но пришлось перейти на совместимый вариант без динамического кода. Благодаря этому DI-контейнер сохранил работоспособность в условиях жёстких ограничений расширений.

3. OpenAI SDK и браузерные ограничения

Сам пакет OpenAI SDK в браузере требует включения опции dangerouslyAllowBrowser: true. Это защита от случайной утечки API-ключа. В моём прототипе ключ хранится в chrome.storage.local в открытом виде. Для расширения это допустимо, но всё же стоит добавить хотя бы лёгкую обфускацию.

Преимущества DI-контейнера

DI-контейнер @teqfw/di подтянул esm-модули OpenAI SDK как обычные зависимости. Это дало сразу два эффекта: код можно тестировать в Node.js и без изменений запускать в Chrome Extension. Контейнер работает только с esm-модулями SDK, что соответствует современному формату.

Неделю назад я выпустил первую стабильную версию @teqfw/di, но уже появились новые запросы на доработку: нужен «безопасный режим» без new Function. Этот эксперимент показал, что даже под жёсткими ограничениями MV3 можно выстраивать гибкую архитектуру на основе @teqfw/di.