Работа над Lumberjack v14, расширяемой библиотекой протоколирования для Angular

Иллюстрация на обложке от DALL-E.

Мы с @nachovazquez уже несколько месяцев работаем над следующим выпуском Lumberjack.

Поддержание инструментария для разработчиков

Когда мы внедряли вторую версию Lumberjack, мы использовали Angular CLI с настроенными конфигурациями Angular architect для поддержки проектов библиотеки рабочего пространства, ESLint, Prettier и Jest.

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

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

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

Кросс-версионная совместимость

В текущей версии Lumberjack, версии 2.0, мы можем поддерживать многие крупные и мелкие релизы Angular, что важно для библиотеки, основанной на плагинах, чтобы облегчить работу разработчикам плагинов.

Однако опция частичной компиляции Ivy была отмечена как стабильная в Angular версии 12.2. В настоящее время последней версией Angular является версия 14.1. Теперь это вопрос времени, когда компилятор совместимости Angular (NGCC) будет удален из Angular, что нарушит совместимость с пакетами библиотек, совместимых с View Engine.

В идеале, мы бы хотели продолжать поддерживать несколько основных и второстепенных версий Angular с одной основной версией Lumberjack. Версия Angular, удаляющая NGCC, станет вехой, завершающей обратную совместимость для библиотек Angular без дополнительных инструментов.

Для Lumberjack версии 2 мы разработали Angular Versions GitHub Action для проверки кросс-версионной совместимости с Angular, RxJS, TypeScript и Node.js. Однако он поддерживает Angular CLI, а не Nx CLI.

Возможно, в какой-то момент мы сможем создать аналогичное действие GitHub для Nx или расширить поддержку действия Angular Versions, чтобы охватить рабочие пространства Nx, использующие предустановку Angular.

Мотивация для предстоящих релизов Lumberjack

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

Мы хотим быть готовы к крупному или минорному релизу Angular, который удалит компилятор совместимости Angular, чтобы не мешать пользователям Lumberjack обновляться до последних релизов Angular.

Мы также хотим изучить новые возможности, которые не были доступны в Angular до версии 14:

• Автономные API
• Разрешение зависимостей с помощью функции inject.

Эти возможности меняют ситуацию в некоторых случаях использования библиотек Angular.

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

Поддержка функции inject в конструкторах классов и инициализаторах свойств может позволить нам удалить внутренние зависимости из классов Lumberjack, предназначенных для расширения:

• LumberjackLogger
• ScopedLumberjackLogger

Миграция в рабочее пространство Nx

Поскольку перенос пользовательского рабочего пространства Angular CLI — это относительно большая работа, мы создали новое рабочее пространство Nx в отдельном репозитории GitHub, ngworker/lumberjack-next. Здесь вы можете следить за нашей работой, если вам интересно увидеть нашу будущую установку, которая использует:

• Nx
• Cypress
• Распределенное выполнение задач (DTE) через Nx Cloud

В качестве дополнительного преимущества, эти усилия начинают преодолевать разрыв между репозиторием Lumberjack и нашим монорепо ngworker, которое в настоящее время содержит Spectacular и использует Nx 12 на момент написания статьи. Кроме того, наш репозиторий ngworker/router-component-store использует Nx 13.

Было бы здорово объединить все наши библиотеки Angular в монорепо, чтобы уменьшить наши усилия по обслуживанию. В качестве дополнительного преимущества мы могли бы использовать Spectacular для интеграционного тестирования библиотек Lumberjack и Router ComponentStore.

Распределенное выполнение задач

В качестве дополнительного преимущества перехода на рабочее пространство Nx мы будем использовать распределенное выполнение задач через Nx Cloud. Даже в таком небольшом рабочем пространстве Nx, как кодовая база Lumberjack, мы можем извлечь выгоду из распределения задач по нескольким агентам, а не иметь один GitHub runner для модульных тестов, один для сквозных тестов, один для проверок и один для сборок.

Это преимущество, учитывая, что большинство наших модульных тестов находится в проекте библиотеки Lumberjack. Вместо того чтобы ждать, пока все модульные тесты будут запущены на одном GitHub runner, модульные тесты распределяются между незадействованными агентами на основе проекта. Это приводит к общему постоянному сокращению времени рабочего процесса CI, так как задачи разумно распределяются Nx Cloud и бегуном GitHub, выступающим в роли координатора, на основе исторического и фактического времени выполнения задач.

Если нам удастся объединить два или более наших Nx-репозиториев в единое рабочее пространство Nx monorepo, преимущества Distributed Task Execution возрастают, поскольку разница между временем выполнения аналогичных целей увеличивается в сочетании с возможностью увеличения количества доступных агентов. Стоит отметить, что агенты DTE — это бегуны GitHub, а не машины, управляемые Nx Cloud. Nx Cloud рассчитывает выполнение задач на основе данных от координатора DTE, также являющегося бегуном GitHub, и кэширует результаты выполнения целей, но цели не выполняются внутри Nx Cloud.

Добавление стратегии параллелизма GitHub Actions

Мне также удалось настроить стратегию параллелизма GitHub Actions, обеспечивающую это:

• Выполняемые рабочие процессы для одной и той же ветки отменяются при появлении новых коммитов. Это устраняет потери вычислений.
• Рабочие процессы на ветке main, то есть когда запрос на притяжение был объединен, выполняются последовательно, а не параллельно. Это предотвращает одновременное выполнение нескольких релизов и других действий по развертыванию с побочными эффектами, чтобы они не влияли друг на друга.

Посмотрите на рабочий процесс CI в репозитории ngworker/lumberjack-next, если вас интересует распределенное выполнение задач с использованием Nx Cloud или стратегии параллелизма GitHub Actions.

Интеграция SonarCloud в рабочее пространство Nx с помощью GitHub Actions

Рабочий процесс Lumberjack vNext CI также является тем местом, где мы будем интегрировать SonarCloud, аналогично нашему текущему рабочему процессу CI.

В настоящее время в рамках работы над Lumberjack vNext нам не хватает уверенности в том, что наши интеграции SonarCloud продолжают работать, чтобы мы могли:

• Обеспечить пороговые значения покрытия тестов
• Устранить запахи кода
• Снизить когнитивную сложность
• Предотвращать очаги безопасности, уязвимости и ошибки
• Устранить дублирование кода

Отказ от схемы ng-add в Angular

Мы с @nachovazquez договорились пока оставить схему ng-add Angular для Lumberjack. Если мы захотим добавить ее обратно в библиотеку, нам придется перенести ее в Nx Devkit с Nx-нативными сквозными тестами, а не в Angular Devkit и наши текущие пользовательские сквозные тесты Jest.

Во-первых, схема ng-add не является самой важной функцией Lumberjack. Другая причина заключается в том, что библиотеки Angular должны ожидать как унаследованные приложения, использующие модули Angular, в частности AppModule, так и автономные приложения Angular без каких-либо модулей Angular, даже без корневого модуля Angular, который обычно называется AppModule.

В настоящее время неясно, как авторы библиотек Angular должны поддерживать оба типа приложений Angular в схемах ng-add.