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

Команда построителя - это все, что можно запустить с nx run (или ng run). Сюда входят build, test и lint.

Включение кеширования

Шаг 1: кеширование будет включено по умолчанию в Nx 10. На данный момент вам нужно добавить следующий код в nx.json

{
  // normal nx.json content...
  "tasksRunnerOptions": {
    "default": {
      "runner": "@nrwl/workspace/src/tasks-runner/tasks-runner-v2",
      "options": {
        "cacheableOperations": ["build", "test", "lint"]
      }
    }
  }
}

Шаг 2: используйте Nx как обычно

cacheableOperations может быть любой командой, которую вы можете выполнить с nx run [someCommand] (или ng run, если вы используете Nx с Angular CLI). При такой конфигурации любые команды build, test или lint будут автоматически кэшироваться, и будет использоваться ранее кэшированный вывод, если он существует.

Кеширование и Nx затронуты

nx affected гарантирует, что команда построителя будет запущена только для затронутых проектов (по сравнению с основной веткой git).

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

Сведения о реализации. Хэш-ключ кеша рассчитывается на основе всех файлов в проекте и любых зависимостей этого проекта. Кэшированное значение по умолчанию сохраняется в node_modules/.cache/nx.

В приведенном выше примере монорепозитория nx affected --target=test будет запускать тесты для myapp-e2e, myapp и feat-home. Если вы запустите эту команду во второй раз, не внося никаких изменений в файл, все три тестовых прогона будут использовать кешированное значение, и консоль очень быстро выведет результаты теста. Теперь предположим, что вы изменили файл в проекте myapp. Это разбивает кеш для myapp (поскольку один из его файлов был изменен) и для myapp-e2e, поскольку была изменена одна из его зависимостей. Runningnx affected --target=test попытается запустить тесты для всех трех проектов: feat-home будет использовать кешированное значение, но myapp и myapp-e2e повторно выполнят свои тесты.

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

Когда это поможет?

Сценарий 1: Тестирование (и линтинг)

  • Вы проводите тестирование проектов, на которые влияет ваш PR
  • Вы меняете некоторые файлы, чтобы исправить некоторые тесты
  • Вы снова запускаете ту же тестовую команду

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

Сценарий 2: переключение ветвей

  • Вы создаете одну ветвь своей кодовой базы
  • Вы переключаетесь на другую ветку и строите ее (которая удаляет предыдущую сборку)
  • Вы переключаетесь обратно на первую ветку и перестраиваете ее

Затем эта сборка попадет в кеш и почти мгновенно появится в папке dist.

Сценарий 3: Портал / Приложение Micro-Frontend

  • У вас есть два или более взаимозависимых приложения (следовательно, две точки входа), например приложение api и приложение client, или несколько клиентских приложений, обслуживаемых вместе в стиле портала или микро-интерфейса.
  • Одно из приложений будет удалено из вашей dist папки.
  • Не внося никаких изменений в это приложение или его зависимости, вы перестраиваете его.

Затем эта сборка попадет в кеш и почти мгновенно появится в папке dist.

Проблема с построением из исходников

Если вы создаете свое приложение на Java, Go и .NET, вы, вероятно, создадите отдельные части приложения, а затем будете использовать скомпилированные выходные данные.

Напротив, в большинстве случаев Webpack собирает все приложение из исходного кода. Это затрудняет кеширование. (Bazel и другие инструменты, использующие кеширование, сталкиваются с той же проблемой.)

Итак, в нашем примере выше, если мы запустили nx affected --target=build, а затем изменили проект myapp и запустили ту же команду, кешированное значение для feat-home не могло быть повторно использовано Webpack.

С помощью Nx вы можете сделать feat-home собираемым и использовать его выходные данные для связывания окончательного приложения с Webpack. В этом случае будет использоваться кешированное значениеfeat-home, но настройка разработчика станет более сложной. Другими словами, вы можете настроить свои проекты на постепенное их создание, что позволит использовать кеширование, но потребует более сложных настроек, которые негативно повлияют на опыт разработчиков для малых / средних проектов.

Более светлое будущее - распределенное кэширование

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

Сборки для разработчиков

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

CI сборки

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

Учить больше

Если вам это понравилось, нажмите 👏 ниже. Следите за Исааком Манном и @nrwl_io, чтобы узнать больше о разработке программного обеспечения.