Вот именно такой вопрос был задан в первом же комментарии к статье "DI-контейнер на чистом JavaScript без TypeScript и reflect-metadata" уважаемого @alexander_kubarski. Я когда-то и сам на Хабре отвечал на этот вопрос ("Зачем нужно внедрение зависимостей в JS"), и уважаемый @Wroud тоже ("Dependency Injection в JavaScript: зачем он вам нужен"), но непонимание места и значения DI у JS-разработчиков всё равно присутствует. Попробую ответить на этот вопрос ещё раз:

Внедрение зависимостей помогает снизить стоимость верификации сложного приложения. Оно отделяет компонент от выбора конкретного окружения и позволяет проверять его относительно явных ожиданий, не поднимая каждый раз весь граф реальных зависимостей.

Именно для этого используют Inversion of Control в целом и Dependency Injection в частности - во всех языках программирования, а не только в JavaScript.

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

Когда зависимость становится проблемой

Рассмотрим простую функцию:

import {save} from "./storage.mjs";

export async function saveName(name) {
  const value = name.trim().toLowerCase();
  await save(value);
  return value;
}

Она нормализует имя и сохраняет результат.

Проверить возвращаемое значение недостаточно. Внутри легко допустить ошибку:

await save(name);

Функция по-прежнему вернёт "alex", но в хранилище попадёт исходная строка " Alex ".

Чтобы проверить компонент полностью, нужно поднять конкретное хранилище и убедиться, что оно получило правильное значение.

Пока хранилище представляет собой массив в памяти, это почти ничего не стоит. Но реальное хранилище может зависеть от базы данных, файловой системы, конфигурации, сети и логгера.

Тогда проверка одной небольшой функции постепенно превращается в проверку связанного графа компонентов.

Сам код saveName() не стал сложнее. Подорожало окружение, необходимое для доказательства его корректности.

Что меняет внедрение зависимостей

Уберём из функции выбор конкретного хранилища:

export function createSaveName({storage}) {
  return async function saveName(name) {
    const value = name.trim().toLowerCase();
    await storage.save(value);
    return value;
  };
}

Зависимость не исчезла. Функции по-прежнему требуется хранилище.

Изменилось только место, где выбирается его имплементация.

В работающем приложении мы передадим настоящее хранилище:

const saveName = createSaveName({
  storage: databaseStorage,
});

В тесте - минимальный объект, достаточный для проверки поведения компонента:

const saved = [];

const saveName = createSaveName({
  storage: {
    async save(value) {
      saved.push(value);
    },
  },
});

Теперь тест проверяет только ответственность saveName():

имя нормализовано;
результат передан в storage.save();
возвращено правильное значение.

База данных и остальные зависимости хранилища в этой проверке не участвуют.

Статический import фиксирует конкретную связь внутри компонента. DI переносит выбор имплементации в точку сборки приложения.

Где возникает интерфейс

В JavaScript нет обязательной конструкции interface, но ожидания между компонентами всё равно существуют.

В выражении

await storage.save(value);

уже зафиксировано, что зависимость должна предоставить метод save(), принять значение и позволить дождаться завершения операции.

Это и есть интерфейс связи с точки зрения потребителя.

Интерфейс - это описание ожиданий компонента на границе с его зависимостью.

Такой интерфейс можно зафиксировать через JSDoc, TypeScript, документацию, статический анализ и тесты. Конкретный способ вторичен.

Важно другое: после появления явной границы верификацию можно разделить.

Потребитель проверяется относительно интерфейса.

Каждая реальная имплементация отдельно проверяется на соответствие тому же контракту.

Интеграционные тесты при этом не исчезают. Ошибки могут возникать в конкретных сочетаниях базы данных, драйвера и конфигурации. Но проверять можно наиболее значимые связки, а не механически поднимать весь граф для каждого локального теста.

При достаточно полных контрактах значительная часть стоимости проверки начинает расти ближе к сумме числа компонентов и имплементаций, а не к произведению всех возможных конфигураций.

Зачем здесь контейнер

До сих пор DI-контейнер нам не требовался.

Зависимости можно связывать вручную:

const logger = createLogger(config);
const database = createDatabase(config, logger);
const storage = createStorage(database, logger);
const service = createService(storage, logger);
const controller = createController(service, logger);

В небольшом приложении такая сборка обычно прозрачнее любого контейнера.

Проблема возникает позже, когда приложение состоит из большого числа относительно независимых компонентов. Их разрабатывают разные команды, отдельные разработчики или ИИ-агенты. Каждый компонент добавляет свои зависимости и правила сборки.

Центральный bootstrap начинает разрастаться. Для подключения нового модуля разработчику приходится понимать не только свой компонент, но и значительную часть общей композиции приложения.

Сложность становится уже не только технической, но и организационной.

DI-контейнер превращает композицию системы в общий протокол.

Модуль объявляет, какие зависимости ему нужны и какие имплементации он предоставляет. Контейнер собирает из этих правил рабочий граф.

Разработчику одного модуля больше не обязательно понимать устройство всей системы. Ему достаточно соблюдать соглашения интеграции.

Это особенно важно для ИИ-агентов. Агент надёжнее изменяет локальный модуль по известным правилам, чем редактирует вручную центральную точку сборки, для понимания которой требуется глобальный контекст проекта.

DI снижает связанность компонента с конкретным окружением. DI-контейнер снижает зависимость разработчика от знания всей системы.

Контейнер не создаёт архитектурные границы и не делает компоненты автоматически независимыми. Если зависимости скрыты, интерфейсы не определены, а правила связывания случайны, контейнер лишь автоматизирует создание плохо устроенного графа.

Сначала появляются компоненты, явные зависимости и контракты. Затем может понадобиться инструмент, который обслуживает их композицию.

Когда контейнер не нужен

Размер проекта сам по себе ещё не является достаточным критерием.

Контейнер не нужен, если граф зависимостей остаётся небольшим, понятным и стабильно собирается вручную.

Он также не нужен для чистых функций, локальных преобразований и небольших утилит, статический импорт которых не мешает независимой проверке.

Даже наличие нескольких имплементаций ещё не требует контейнера. Их вполне можно выбирать вручную в одной точке композиции.

Контейнер становится полезен, когда сходятся несколько факторов:

много относительно независимых модулей;
сложный или изменчивый граф зависимостей;
несколько конфигураций приложения;
параллельная работа разных разработчиков или агентов;
ручная композиция требует слишком много глобального знания.

Граница проходит по стоимости сборки и интеграции системы.

Ответ

JavaScript позволяет подменить почти любой объект во время выполнения. Но сама возможность подмены ещё не создаёт устойчивой архитектурной границы.

DI делает зависимость явной и переносит выбор имплементации за пределы компонента. Это позволяет отдельно проверять потребителей и реализации и тем самым удерживать стоимость верификации под контролем.

DI-контейнер решает следующую проблему: автоматизирует композицию большого числа таких компонентов.

Поэтому точный ответ на вопрос из заголовка звучит так:

DI-контейнер нужен JavaScript-приложению тогда, когда внедрение зависимостей уже помогает разделять и независимо проверять компоненты, а ручная сборка их графа становится самостоятельным источником технической и организационной сложности.

В небольшом приложении контейнер, скорее всего, будет лишним.

В крупной модульной системе, которую параллельно развивают относительно независимые разработчики или ИИ-агенты, он становится общим механизмом интеграции.

P.S.

Данный пост является сокращённой, но достаточной выжимкой более подробной версии разбора с моего сайта. Если кто-то предпочитает TL;DR - wellcome, как говорится.