Вышел Nx 23.2: Oxlint, Oxfmt, более лаконичный вывод CLI и улучшенное кэширование

Я с нетерпением ждал этого релиза! В нем появилось мое любимое нововведение: инструментарий Oxc прибыл в Nx вместе с @nx/oxlint и oxfmt. Но это еще не все, давайте погрузимся в детали!

Содержание

• Oxlint и Oxfmt появляются в Nx
• Плагин @nx/oxlint
• Встроенная поддержка Oxfmt
• Сокращение вывода логов для лучшей читаемости и экономии токенов ИИ
• Строка состояния для пользовательского интерфейса терминала
• Nx и полиглот-монорепозитории
• Запуск Nx внутри изолированных сред агентов
• Улучшенное кэширование между изолированными средами, рабочими деревьями и клонами репозитория
• Запуск миграций по одной
• Angular 22.1 и обновления фреймворка
• Vitest во всех генераторах
• Улучшенная поддержка Bun
• Прочие улучшения
• nx release понимает селекторы
• Более быстрая миграция в inferred-формат
• Упрощенная и более мощная конфигурация Nx Cloud
• Спасибо сообществу
• Как обновить Nx
• Узнать больше

Oxlint и Oxfmt появляются в Nx

Как и многие из нас, я был большим поклонником инструментария Oxc и активно продвигал его внутри команды Nx.

В версии 23.2 мы добавляем Oxlint и Oxfmt.

Плагин @nx/oxlint

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

Он включает плагин вывода, который обнаруживает Oxlint в ваших конфигурационных файлах, генератор конфигурации и мост, который запускает правило Nx enforce-module-boundaries под управлением JS-плагина Oxlint.

Чтобы начать использовать его, добавьте плагин:

Это установит oxlint, если он у вас не установлен, зарегистрирует плагин и запишет корневой файл .oxlintrc.json, если в рабочем пространстве еще нет конфигурации Oxlint. После этого вы получаете выводимую, кэшируемую задачу линтинга для каждого проекта. Плагину требуется Oxlint версии 1.70.0 или новее.

Вам не нужно переключать все сразу. Oxlint разработан для работы рядом с ESLint. Когда вы устанавливаете плагин, он занимает первое доступное имя цели (если оно еще не занято), перебирая список lint, oxlint, oxlint:lint, oxlint-lint. Например: рабочее пространство без других линтеров получает lint, рабочее пространство, где ESLint уже занимает lint, получает oxlint, и вы можете запускать оба инструмента параллельно, пока переносите код.

ESLint по-прежнему играет свою роль

Скорее всего, вы еще некоторое время будете использовать ESLint. Прямо сейчас Oxlint не парсит правила, читающие JSON, HTML или шаблоны Angular, так как парсер отсутствует, поэтому эти правила пока должны оставаться на ESLint.

Выводимая цель становится доступной в рабочем пространстве сразу после выполнения команды nx add. Генератор конфигурации добавляет специфичные для проектов плагины, когда они нужны проекту. Например, проект на React может расширить корневую конфигурацию правилами для React:

А что с производительностью?

Это не формальный тест производительности, но я опробовал его на монорепозитории с 67 проектами, поддерживающими линтинг.

Как видите, правила границ модулей занимают здесь много времени, так как они выполняются через мост JS-API Oxlint. Существует возможность улучшить это за счет пакетной обработки работы, над чем мы сейчас и работаем.

Встроенная поддержка Oxfmt

Prettier раньше был жестко зашит в Nx через команду nx format. Начиная с этого релиза Nx теперь определяет используемый форматтер непосредственно из конфигурационных файлов: Prettier или Oxfmt.

Чтобы настроить Oxfmt, запуск генератор инициализации @nx/js:

Это добавляет зависимость и создает файл .oxfmtrc.json с установленным параметром singleQuote. После этого nx format:write и nx format:check просто используют его. Настройки по умолчанию в Oxfmt немного отличаются от Prettier, поэтому стоит взглянуть на сгенерированный .oxfmtrc.json, если вам важно точное совпадение с прежним выводом.

Если настроены оба форматтера, побеждает Oxfmt, а Nx выдает одноразовое предупреждение, так что выбор не останется незамеченным. А отсутствие настроенного форматтера больше не является ошибкой: nx format выводит предупреждение и завершается с кодом 0.

А что с производительностью?

Мы провели проверку в репозитории Nx и увидели примерно 18–20-кратное ускорение проверок Oxfmt (например, nx format:check) и операций записи. Имейте в виду, что это не научно поставленное измерение производительности, поэтому относиться к цифрам стоит с определенной долей скептицизма.

Сокращение вывода логов для лучшей читаемости и экономии токенов ИИ

Краткость — сестра таланта! Это важно для людей и еще важнее для агентов. Больший объем вывода означает большие затраты на токены, так как агентам искусственного интеллекта приходится перечитывать и обрабатывать его.

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

Мы измерили это на кодовой базе Nx с помощью команды nx run-many -t test для 30 пакетов плагинов со 100% попаданием в кэш при обоих запусках, так что единственной переменной был рендеринг:

• Полностью успешный запуск (31 закэшированный успех): с 205 452 байт до 3 083 байт, сокращение в 66,6 раза.
• Смешанный запуск (32 успешных, 2 неудачных): с 326 457 байт до 45 846 байт, сокращение в 7,1 раза.

Если ваш агент запускает Nx, он теперь автоматически получает свернутый вывод. То же самое относится и к CI, где это делает логи GitHub Actions значительно короче для просмотров. Ошибки по-прежнему выводятся полностью, поэтому ничего важного для отладки вами или агентом не потеряется.

Это стиль вывода только для статических ошибок, который Nx теперь выбирает по умолчанию в CI и других не интерактивных запусках. Если вы хотите вернуть полный вывод, передайте флаг --output-style=static для отдельной команды или установите NX_DEFAULT_OUTPUT_STYLE=static для всей сборки CI.

Строка состояния для пользовательского интерфейса терминала

В этом релизе TUI (терминальный интерфейс) Nx получил несколько крутых обновлений.

В нижней строке появилась строка состояния во всю ширину. Слева отображается счетчик прогресса с текущим временем выполнения (63/174 (1m 23s)), при клике на который открывается Nx Cloud.

Вторая половина — это поиск по панели в стиле Vim. Если вы нажжете пробел, чтобы открыть панель с подробностями, а затем нажжете /, вы сможете искать по всему журналу прокрутки с инкрементальным переходом по мере ввода. Это работает в стиле Vim: нажатие Enter позволяет переключиться на навигацию n/N.

Задачи, выполняющиеся внутри pty интерфейса TUI, теперь также пересылают события мыши и изменения размера, поэтому интерактивный инструмент под управлением Nx ведет себя так же, как в вашем терминале.

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

Nx и полиглот-монорепозитории

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

Nx + TanStack + Rust

Nx уже некоторое время поддерживает .NET, а версия 23.2 делает кэширование в @nx/dotnet еще лучше.

Microsoft.Extensions.ApiDescription.Server записывает документ OpenAPI во время сборки туда, куда указывает <OpenApiDocumentsDirectory>. Nx не знал, что эти документы являются результатами сборки, поэтому все, что их использует, например цель кодогенерации OpenAPI-в-TypeScript, оказывалось пустым при свежем клонировании или у агента CI, когда сборка восстанавливалась из кэша. Анализатор MSBuild теперь автоматически определяет их и объявляет результатами сборки, поэтому ручное переопределение вывода в nx.json больше не нужно (#36788).

Крейгори из нашей команды также подробно изучил, как можно реализовать полностековую типобезопасность в монорепозитории Nx с бэкендом на .NET и фронтендом на JavaScript. Читайте полную статью в блоге здесь.

Запуск Nx внутри изолированных сред агентов

Агенты для написания кода часто используют песочницы (sandbox), где доступ к файловой системе и сокетам ограничен разрешенным списком. Это приводило к ряду проблем, так как Nx открывает сокеты Unix для демона, рабочих процессов плагинов и разветвленных (forked) задач. В результате эти задачи завершались ошибкой.

Теперь команда nx configure-ai-agents записывает правила доступа, необходимые для Claude Code и других сред, охватывая корневые каталоги сокетов Nx, а также права на чтение и запись в них.

Улучшенное кеширование в песочницах, рабочих деревьях (worktrees) и клонах репозиториев

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

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

Теперь мы перенесли кеш Nx и данные рабочего пространства в ~/.nx, что обеспечивает уникальный путь и стабильный ключ кеша в разных местах на вашем компьютере. Больше никаких холодных запускaв.

Запуск миграций по одной

В версии v23 мы выпустили ряд улучшений для миграций Nx, включая возможность для агентов подключаться и помогать. У нас есть действительно потрясающие улучшения в области миграций с помощью агентов, но они еще не готовы к полноценному релизу, так что следите за новостями.

Тем временем, вот небольшое улучшение для удобства работы, позволяющее запускать отдельные миграции проще:

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

Angular 22.1 и обновления фреймворка

Nx 23.2 поддерживает Angular 22.1. Если вы используете плагин Nx для Angular (@nx/angular), команда nx migrate latest выполнит обновление версии за вас.

Кроме того, в angular-rspack появились исправления, о которых стоит упомянуть:

• сборка стала быстрее и лучше согласована со сборщиком приложений esbuild
• компоненты пересобираются корректно при изменении их шаблонов или стилей на Windows.
• сборка больше не завершается аварийно при использовании массива styleUrls, не являющегося массивом.
• Тестирование компонентов Cypress снова работает в Angular 22.1.
• Пакеты, связанные с Webpack, были перемещены в необязательные зависимые пакеты (optional peer dependencies), поэтому они не подтягиваются, если вы не используете webpack.

Vitest во всех генераторах

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

Теперь это исправлено: Vitest можно выбрать везде, где лежащий в основе генератор действительно его поддерживает. Генераторы Node, Nest и Express также получили поддержку Vitest, а @nx/plugin теперь может генерировать e2e-тесты на базе Vitest.

Улучшенная поддержка Bun

В этот раз мы получили несколько действительно классных вкладов в поддержку Bun, в том числе от самого Джареда Самнера (Jarred Sumner).

• @cogwirrel добавил поддержку каталогов зависимостей Bun (#36434). Nx уже разрешал ссылки catalog: для pnpm и yarn, но возвращал неразобранную исходную строку для Bun, из-за чего такие генераторы, как @nx/vitest:configuration, аварийно завершались с ошибкой Cannot read properties of null (reading 'version') в любом рабочем пространстве Bun, где зависимости управлялись через каталог. Теперь ссылки на каталоги разрешаются в генераторах, миграциях, версионировании релизов, очистке lock-файлов и проверках зависимостей для линтинга. Реализация следует фактической семантике Bun, а не pnpm, что было проверено эмпирически: расположение каталогов работает по принципу «все или ничего», а значение по умолчанию не является особенным, как в pnpm.

@cogwirrel добавил поддержку каталогов зависимостей Bun (#36434). Nx уже разрешал ссылки catalog: для pnpm и yarn, но возвращал неразобранную исходную строку для Bun, из-за чего такие генераторы, как @nx/vitest:configuration, аварийно завершались с ошибкой Cannot read properties of null (reading 'version') в любом рабочем пространстве Bun, где зависимости управлялись через каталог. Теперь ссылки на каталоги разрешаются в генераторах, миграциях, версионировании релизов, очистке lock-файлов и проверках зависимостей для линтинга. Реализация следует фактической семантике Bun, а не pnpm, что было проверено эмпирически: расположение каталогов работает по принципу «все или ничего», а значение по умолчанию не является особенным, как в pnpm.

• @Jarred-Sumner, разработчик Bun, исправил парсинг файла bun.lock для версий lock-файлов 2 и 3 (#36666).

@Jarred-Sumner, разработчик Bun, исправил парсинг файла bun.lock для версий lock-файлов 2 и 3 (#36666).

• @theescodes исправил работу module federation для Bun, удалив суффикс версии из имен npm-зависимостей (#34960).

@theescodes исправил работу module federation для Bun, удалив суффикс версии из имен npm-зависимостей (#34960).

Прочие различные улучшения

nx release понимает селекторы

Параметр --projects раньше принимал только точные имена проектов. Теперь он работает через ту же логику сопоставления проектов, что и nx run-many, поэтому теги, шаблоны glob, шаблоны каталогов, исключения и нечеткий поиск по имени (fuzzy match) работают полноценно. Селектор, не сопоставивший ни с чем, выводит понятную ошибку об отсутствии совпадений вместо ошибки внутренней проблемы.

Более быстрая миграция convert-to-inferred

Конвертация convert-to-inferred помогает перейти на новый синтаксис вывода Nx вместо явных исполнителей (executors). Выполнять миграцию стоит, так как она убирает дублирующую конфигурацию, которую в противном случае приходится поддерживать одновременно в project.json и собственном конфигурационном файле инструмента.

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

Упрощенная и более мощная конфигурация Nx Cloud

Раньше при настройке Nx Agents с помощью Nx Cloud вам приходилось объединять все в один вызов start-ci-run в главном файле YAML вашего CI-пайплайна. Недавно мы это улучшили.

Теперь эта конфигурация находится в файле .nx/ci-config.yaml в вашем репозитории, а npx nx-cloud start-nx-agents — это команда, которая вообще не требует флагов конфигурации.

.nx/ci-config.yaml

Ваш файл CI сокращается до одной строки:

.github/workflows/ci.yml

Луи из нашей команды описал все подробности в своем посте в блоге: Мы упростили конфигурацию CI в Nx.

Огромное спасибо примерно 25 внешним контрибьюторам, которые выпустили исправления и функции в версиях 23.1 и 23.2. Работа над Bun, упомянутая выше, является самым ярким примером, но все выходит далеко за ее рамки: @ATKasem, @christopher-buss, @seungdeok, @paustint, @sanshan, @harshmathurx, @Squixx, @Roozenboom, @kevindcode, @Optischa, @prafful1234, @Tusharkhadde, @djohnson-aperture, @dbwodlf3 и многие другие внесли свои изменения в этом цикле.

Если вы хотели внести свой вклад, метка community — отличное место для начала. Эти ребята уже сделали это. Вы можете быть следующим.

Как обновить Nx

Как всегда, обновление до последней версии Nx происходит просто:

Это проанализирует ваше рабочее пространство и создаст файл миграции со всеми необходимыми обновлениями. Просмотрите изменения, а затем примените их:

Новичок в Nx? Создайте новое рабочее пространство с помощью npx create-nx-workspace@latest или запустите nx init внутри существующего рабочего пространства npm/pnpm, чтобы начать использовать Nx с ним. Перейдите к руководству по началу работы (Getting Started) для пошагового прохождения.

Узнать больше

• Документация Nx
• Сообщество Nx в Discord
• X / Twitter
• Репозиторий Nx на GitHub
• Канал Nx на YouTube