Integration of @teqfw/di and OpenAI SDK in a Chrome extension

Publication date: 2025-08-28

I tried building a prototype Chrome (MV3) extension to test how @teqfw/di works in a restricted environment and when connecting a third-party SDK. Three problem areas emerged right away: container configuration, CSP restrictions, and running the OpenAI SDK in the browser.

1. Relative paths

Problem: an extension cannot use absolute paths when configuring the namespace in the container. Absolute paths inside a Chrome extension behave differently from a regular browser or Node.js.

Solution: always use import.meta.url to build relative paths when configuring the object container.

2. CSP and dependency parsing

CSP in MV3 completely forbids new Function. An earlier version of the container used this trick to parse dependencies, but it had to switch to a compatible option without dynamic code. Thanks to this, the DI container keeps working under the strict extension limitations.

3. OpenAI SDK and browser restrictions

The OpenAI SDK itself requires enabling the dangerouslyAllowBrowser: true option in the browser. It's a safeguard against accidentally leaking the API key. In my prototype the key is stored in chrome.storage.local in plain text. That's acceptable for an extension, but it's still worth adding at least light obfuscation.

Benefits of the DI container

The DI container @teqfw/di pulled in the OpenAI SDK as regular ESM dependencies. This gave two benefits at once: the code can be tested in Node.js and run in the Chrome extension without changes. The container works only with the SDK's ESM modules, which matches the modern format.

A week ago I released the first stable version of @teqfw/di, but new improvement requests have already appeared: a "safe mode" without new Function is needed. This experiment showed that even under MV3's strict limits you can build a flexible architecture based on @teqfw/di.