Перейти к основному содержимому
Неофициальный Бета-перевод

Эта страница переведена PageTurner AI (бета). Не одобрена официально проектом. Нашли ошибку? Сообщить о проблеме →

Конфигурация

Конфигурация Lerna разделена на два файла: lerna.json и nx.json.

Lerna.json

npmClient​

Это значение важно задать, если вы используете не npm в качестве менеджера пакетов (например, yarn или pnpm). Это позволяет Lerna адаптировать внутреннюю логику при разрешении конфигурации и пакетов. Особенно актуально для pnpm, так как он использует отдельный файл pnpm-workspaces.yaml для определения конфигурации рабочих пространств.

packages​

По умолчанию Lerna пытается повторно использовать конфигурацию workspaces из вашего менеджера пакетов. Если вы хотите указать подмножество доступных пакетов для работы Lerna, используйте свойство packages – оно определяет, где искать файлы package.json.

lerna.json
{
  "packages": ["packages/*"]
}

version​

Lerna поддерживает два режима публикации пакетов: fixed (фиксированный) и independent (независимый). В фиксированном режиме все затрагиваемые пакеты публикуются с одинаковой версией. Последняя опубликованная версия сохраняется в lerna.json следующим образом:

lerna.json
{
  "version": "1.2.0"
}

В независимом режиме каждый пакет версионируется отдельно, и lerna.json будет выглядеть так:

lerna.json
{
  "version": "independent"
}

Подробнее в документации по версионированию и публикации.

commands​

Файл lerna.json также позволяет задавать опции для каждой команды:

{
  "command": {
    "version": {
      "allowBranch": "main",
      "conventionalCommits": true
    }
  }
}

Доступные опции смотрите в API документации.

Nx.json

ПРИМЕЧАНИЕ: "{projectRoot}" и "{workspaceRoot}" – специальные синтаксические конструкции, которые интерполируются раннером задач при выполнении команды. Не заменяйте их фиксированными путями – это снижает гибкость конфигурации.

nx.json
{
  "namedInputs": {
    "default": ["{projectRoot}/**/*"],
    "prod": ["!{projectRoot}/**/*.spec.tsx"]
  },
  "targetDefaults": {
    "build": {
      "dependsOn": ["prebuild", "^build"],
      "inputs": ["prod", "^prod"],
      "outputs": ["{projectRoot}/dist"],
      "cache": true
    },
    "test": {
      "inputs": ["default", "^prod", "{workspaceRoot}/jest.config.ts"],
      "cache": true
    }
  }
}

Стандарты для целей (Target Defaults)​

Цели (targets) – это имена npm-скриптов. В разделе targetDefaults вы можете добавить метаданные для скриптов (например, сборки) каждого проекта в репозитории.

cache​

При значении true указывает Nx кешировать результаты выполнения скрипта. В большинстве репозиториев все недолгие задачи (кроме serve) должны быть кешируемыми.

dependsOn​

Цели могут зависеть от других целей. Типичный сценарий: сначала собрать зависимости проекта, затем сам проект. Свойство dependsOn определяет зависимости для конкретной цели.

"dependsOn": [ "prebuild", "^build"] указывает Nx, что каждый скрипт build требует предварительного выполнения скрипта prebuild в том же проекте и скриптов build во всех зависимостях.

inputs и namedInputs​

Массив inputs определяет критерии кеширования результатов выполнения скрипта. Существует три типа входных данных:

Наборы файлов (Filesets)

Примеры:

  • {projectRoot}/**.*.ts

  • эквивалентно {fileset: "{projectRoot}/**/*.ts"}

  • {workspaceRoot}/jest.config.ts

  • эквивалентно {fileset: "{workspaceRoot}/jest.config.ts}

Рантайм-входы (Runtime Inputs)

Примеры:

  • {runtime: "node -v"}

Обратите внимание: результирующее значение хешируется и никогда не отображается.

Переменные окружения (Env Variables)

Примеры:

  • {env: "MY_ENV_VAR"}

Обратите внимание: результирующее значение хешируется и никогда не отображается.

Именованные входные данные

Примеры:

  • inputs: ["prod"]

  • эквивалентно inputs: [{input: "prod", projects: "self"}]

Один и тот же glob-шаблон часто встречается в разных местах (например, набор файлов prod исключает тестовые файлы во всех проектах). Чтобы избежать ошибок синхронизации, рекомендуем определять именованные входные данные для централизованного использования.

Использование ^​

Примеры:

  • inputs: ["^prod"]

  • эквивалентно inputs: [{input: "prod", projects: "dependencies"}]

Как и в dependsOn, символ "^" означает "зависимости". Проиллюстрируем эту важную концепцию примером:

"test": {
  "inputs": [ "default", "^prod" ]
}

Данная конфигурация означает: цель тестирования зависит от всех исходных файлов проекта и только от prod-файлов (не тестовых) его зависимостей. Тестовые файлы считаются приватными. Например, если проект remixapp зависит от библиотеки header, изменения в тестах header не повлияют на цель тестирования remixapp.

Выходные данные (outputs)​

"outputs": ["{projectRoot}/dist"] указывает Nx, где скрипт сборки создаёт файловые артефакты (это значение по умолчанию, его можно опустить). "outputs": [] означает отсутствие артефактов у цели тестирования. Можно перечислять несколько выходов, включая glob-шаблоны или отдельные файлы.

Обычно эта конфигурация не требуется — Nx использует разумные значения по умолчанию.

Проектная конфигурация​

В похожих проектах всей конфигурацией Nx управляет nx.json. Для проектно-специфичных настроек используйте package.json проекта.

package.json
{
  "name": "parent",
  "scripts": {
    "build": "...",
    "test": "..."
  },
  "dependencies": {...},
  "nx": {
    "namedInputs": {
      "prod": [
        "!{projectRoot}/**/*.test.tsx",
        "{workspaceRoot}/configs/webpack.conf.js"
      ]
    },
    "targets": {
      "build": {
        "dependsOn": [
          "^build"
        ],
        "inputs": [
          "prod",
          "^prod"
        ],
        "outputs": [
          "{workspaceRoot}/dist/parent"
        ]
      }
    }
    "implicitDependencies": ["projecta", "!projectb"]
  }
}

Помните: namedInputs и targetDefaults в nx.json — лишь значения по умолчанию. Их копирование в package.json каждого проекта даст идентичный результат.

Каждый проект наследует именованные входы по схеме: {...namedInputsFromNxJson, ...namedInputsFromProjectsPackageJson}. Для dependsOn каждой цели/скрипта действует правило: dependsOnFromProjectsPackageJson || dependsOnFromNxJson. То же правило применяется для inputs и outputs.

inputs и namedInputs​

Определение inputs для указанной цели заменяет набор входных данных для этого имени цели, определённый в nx.json. С использованием псевдокода: inputs = packageJson.targets.build.inputs || nxJson.targetDefaults.build.inputs.

Переопределение именованных входов позволяет централизовать настройки в nx.json:

"test": {
  "inputs": [
    "default",
    "^prod"
  ]
}

Проекты могут определять свой набор prod-файлов без переопределения входов для цели test.

package.json
{
  "name": "parent",
  "scripts": {
    "build": "...",
    "test": "..."
  },
  "dependencies": {...},
  "nx": {
    "namedInputs": {
      "prod": [
        "!{projectRoot}/**/*.test.js",
        "{workspacRoot}/jest.config.js"
      ]
    }
  }
}

В этом случае Nx автоматически использует корректный вход prod для каждого проекта.

dependsOn​

Определение dependsOn для заданной цели заменяет настройку dependsOn из nx.json (псевдокод: dependsOn = packageJson.targets.build.dependsOn || nxJson.targetDefaults.build.dependsOn).

Выходные данные (outputs)​

Определение outputs для конкретной цели (target) заменит outputs для этого имени цели, указанные в nx.json. В псевдокоде это выражается как outputs = packageJson.targets.build.outputs || nxJson.targetDefaults.build.outputs.

implicitDependencies​

Строка "implicitDependencies": ["projecta", "!projectb"] указывает Nx, что родительский проект зависит от projecta, даже если эта зависимость не указана в его package.json. Nx будет обрабатывать такую зависимость так же, как явные зависимости. Также эта строка указывает игнорировать явную зависимость от projectb, даже если она присутствует.

Дополнительная конфигурация​

Дополнительные способы настройки задач и кэширования описаны в документации Nx.