---
title: "Интеграция @teqfw/di и OpenAI SDK в расширении Chrome"
description: "Прототип MV3-расширения с использованием @teqfw/di показал три проблемы: работа с путями, ограничения CSP и запуск OpenAI SDK в браузере. DI-контейнер упростил тестирование кода в Node.js и запуск в расширении, но уже потребовал доработок."
date: 2025-08-28
display_date: "28 августа 2025"
image: "/img/blog/2025/08/28-01-di-openai-extension.png"
image_alt: "@teqfw/di и OpenAI SDK"
---

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

<zoom-img
    src="/img/blog/2025/08/28-01-di-openai-extension.png"
    alt="@teqfw/di и OpenAI SDK"
    width="100px"
    style="float: left; margin: 15px 15px 0 0"
  ></zoom-img>

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

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

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

- В **Node.js** модули грузятся по `file://…`.

- В **браузере** — по `http(s)://…`.

- В **Chrome Extension** — только через `chrome-extension:// /…`.

**Решение**: при конфигурировании контейнера объектов всегда использовать
    `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](https://github.com/teqfw/di) подтянул esm-модули OpenAI SDK как
    обычные зависимости. Это дало сразу два эффекта: код можно тестировать в **Node.js** и без изменений
    запускать в **Chrome Extension**. Контейнер работает только с **esm-модулями** SDK, что
    соответствует современному формату.

Неделю назад я выпустил первую стабильную версию
    [@teqfw/di](https://wiredgeese.com/ru/blog/2025/20250821-02-teqfw-di-release.html), но уже появились новые
    запросы на доработку: нужен «безопасный режим» без `new Function`. Этот эксперимент показал, что даже под
    жёсткими ограничениями MV3 можно выстраивать гибкую архитектуру на основе
    **@teqfw/di**.