yarn workspaces focus: как установить зависимости одного workspace

Что значит «установить только один workspace» на практике

Focus не превращает monorepo в независимый репозиторий. Команда строит install так, будто целевое приложение и те внутренние workspace, которые ему реально нужны, составляют проект. Если `web-app` зависит от `@company/ui`, а тот — от `@company/config`, оба внутренних пакета должны остаться доступными; иначе приложение не соберётся. Независимый `admin-panel`, на который нет пути зависимости, не нужен выбранному фокусу. Такой подход уменьшает область link/install, но результат всё равно следует проверять той же командой build, которой будет собираться сервис. Нельзя ориентироваться только на размер каталога после установки.

Важно: Focus сохраняет транзитивные workspace-зависимости. Если внутренний пакет нужен приложению, «только один workspace» не означает физически один каталог.

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

1. Уточните workspace name: Возьмите точное имя из его `package.json`, а не угадывайте по имени папки.
2. Проверьте граф внутренних зависимостей: Убедитесь, что приложение явно декларирует все используемые workspace-пакеты и не полагается на случайно доступные зависимости корня.
3. Запустите focus из корня: Используйте `yarn workspaces focus <workspace-name>`; без имени команда фокусируется на активном workspace.
4. Добавьте `--production` для runtime-образа: Флаг оставит обычные dependencies и исключит devDependencies, если они действительно не нужны финальному этапу.
5. Соберите приложение: Запустите build/test после focus. Ошибки импорта часто показывают скрытые undeclared dependencies.
6. Повторите в чистой среде: Для Docker или CI проверяйте результат без остаточного `node_modules`, PnP artifacts или cache из предыдущих шагов.

Совет: Если focus внезапно ломает импорт, сначала ищите незадекларированную зависимость. Полная установка могла случайно скрывать ошибку manifest.

Режимы yarn workspaces focus

• `yarn workspaces focus app`. Фокус на app и workspace-зависимостях. CI/build одного приложения
• `yarn workspaces focus app --production`. То же, но без devDependencies. Подготовка runtime-окружения, если build уже завершён
• `yarn workspaces focus`. Фокус на активном workspace. Работа из контекста конкретного workspace
• `yarn workspaces focus -A --production`. Весь проект, только production dependencies. Эквивалент старого подхода к production install для всего проекта

Почему в Zero-Installs экономия может оказаться небольшой

Yarn прямо предупреждает, что при Zero-Installs польза focus умеренная: cache уже содержит пакеты всего проекта, а отличие полной и сфокусированной установки может свестись к небольшим изменениям в `.pnp.cjs`, при этом workflow становится сложнее. Это хороший пример, почему нельзя автоматически добавлять focus «для ускорения» в каждый pipeline. Сначала измерьте время fetch/link и размер передаваемого build context. Если основная масса лежит в checked-in cache, focus её не устранит. Если же проект использует node_modules linker и образ собирается по многоступенчатой схеме, ограничение install-графа может быть заметнее.

Предупреждение: Оптимизируйте измеренный bottleneck. В Zero-Installs focus может добавить сложность почти без выигрыша по cache.

Как использовать focus в multi-stage Docker build

В build-stage обычно нужны devDependencies: компилятор TypeScript, bundler, генераторы кода и тестовые инструменты. Поэтому преждевременный `--production` способен сломать сам build. Более надёжная схема — сначала получить зависимости, достаточные для сборки целевого workspace, собрать артефакт, затем сформировать runtime-stage, где остаются только production-зависимости и результаты build. Конкретный layout зависит от PnP/node_modules linker и фреймворка. Обязательно проверяйте, не копирует ли финальный образ весь monorepo из предыдущего stage: тогда focus не даст ожидаемого уменьшения размера даже при корректной установке.

Диагностика, если focused install не работает

• Имя workspace совпадает с полем `name` в package.json.
• Все импорты из внутренних пакетов отражены в dependencies/peerDependencies по архитектуре проекта.
• Build-инструменты не были случайно удалены флагом `--production`.
• Версия Yarn и linker (`nodeLinker`) совпадают с обычной установкой.
• Нет скрытых артефактов полной установки из предыдущего Docker layer или CI cache.
• Для Zero-Installs учтено, что общий cache остаётся полным.
• После focus приложение запускается в новом чистом runtime, а не только на машине разработчика.

Важно: Не используйте `--production` на этапе, где сборщику ещё нужны devDependencies. Production-фокус уместен после build либо в проекте, где build-инструменты не требуются.

Когда focus действительно стоит оставить в pipeline

Сохраняйте его там, где он решает конкретную задачу: сокращает install/link для одного сервиса, выявляет скрытые зависимости или помогает собрать отдельный deployable unit из большого monorepo. Если метрика времени и размера не меняется, простая полная установка может быть надёжнее и понятнее. Поскольку команда учитывает зависимые workspace автоматически, хороший manifest-граф становится ключевым условием. Наличие focus не заменяет архитектурную дисциплину: общие пакеты должны иметь явные зависимости и собственные build-условия. После любого изменения workspace-графа повторяйте чистую CI/Docker-проверку, иначе локальный cache может скрыть недостающий пакет.

Несколько целевых workspace и общий внутренний пакет

Focus можно применять не только к одному workspace: команда принимает выбранные workspace, а их общие внутренние зависимости включаются по графу. Это полезно, когда один deployable блок состоит, например, из API и worker, использующих общую библиотеку. Но такой набор стоит считать отдельным deployment scope и проверять вместе. Если API случайно импортирует пакет только потому, что worker его притянул, manifests снова скрывают ошибку. Чистая сфокусированная установка должна оставаться воспроизводимой после удаления всех предыдущих install artifacts; иначе вы тестируете состояние машины, а не dependency graph репозитория.

Что учитывать

Yarn прямо предупреждает, что при Zero-Installs польза focus умеренная: cache уже содержит пакеты всего проекта, а отличие полной и сфокусированной установки может свестись к небольшим изменениям в `.pnp.cjs`, при этом workflow становится сложнее. Это хороший пример, почему нельзя автоматически добавлять focus «для ускорения» в каждый pipeline. Сначала измерьте время fetch/link и размер передаваемого build context. Если основная масса лежит в checked-in cache, focus её не устранит. Если же…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. yarn workspaces focus). Пример и формулировки — редакция N1RO на 2026-09-20.

• yarn workspaces focus