Так как версионирование через плагин nx-semantic-release происходит путем анализа изменений по связанным Typescript-импортам, то нам нужно минимизировать эти изменения, для этого в проект подключаем lint-staged и добавляем строгости в Typescript-код.
Подключение и настройка nx-semantic-release плагина для NX-монорепозитория для автоматического создания релиза с последующим деплоем приложений.
Я часто пользуюсь своей утилитой "rucken" по копированию файлов и директорий с кодом, но для генерации конфигураций деплоя по шаблонам я использовал баш скрипты, в которых помимо различных условий происходит копирование через команду "cp" и замена переменных через команду "sed".
На днях подумал и решил что часть с копированием и заменой можно убрать в утилиту "rucken" и тем самым оставить в баш скриптах только логики с условиями.
Всем привет! Меня зовут Иван Кузнецов, я Head of Frontend в Uzum Market. Расскажу о сложностях, с которыми мы столкнулись на пути к реализации микрофронтендовой архитектуры, и поделюсь результатами, которые мы получили в процессе пакетирования наших решений с помощью Lerna. Надеюсь, тебе, дорогой читатель, будет очень интересно :)
Коллекция утилит NestJS-mod предназначена для унификации приложений и модулей NestJS, а также представляет новые логические возможности разделения обязанностей между модулями (System, Core, Feature, Integration, Infrastructure).
В продолжении к предыдущей статьи, погружение в nx.
Практический урок по написанию собственного плагина, на примере react приложения.
Nx Generator: имба или не стоит разбираться?
Всем привет, меня зовут Дима, я angular-разработчик из департамента среднего и малого бизнеса в Тинькофф. Недавно мой коллега рассказал, почему мы выбрали Nx, а я расскажу про самый мощный инструмент Nx — Nx Generator.
Покажу, что нужно установить для запуска генераторов, и объясню, как писать собственные генераторы и создавать с ними шаблонные файлы. А еще рассмотрим генераторы из коробки от Nx. Предлагаю начинать.
Если вы, как и я, заинтересовались микрофронтами и пробуете развернуть проект на Nx, то возможно, у вас встанет вопрос, как в итоге объединить несколько своих микрофронтов в общий проект. По крайней мере, те статьи, которые я находил по этой теме, рассказывали про то, как создать в Nx несколько проектов (в т.ч. на разных фреймворках), как создать к ним компоненты и либы, и на этом всё заканчивалось. Разобравшись, решил оставить инструкцию для других.
Работая с монорепозиторием, ты наверняка слышал о наборе инструментов Nrwl Nx. Если вкратце, то Nx ускоряет и упрощает работу с монорепой, снабжает полезными утилитами. Держи документацию.
Часто работа с Nx заканчивается на имеющихся дефолтных настройках. Все остальное остается черным ящиком. Время сборки проектов начинает расти, а причины так и остаются неизвестными. Может, есть что-то, что способно улучшить работоспособность монорепы и хотя бы частично решить проблемы?
Предлагаю отправиться на изучение официальной документации и поискать лайфхаки вместе со мной. Ниже приведу список полезных инструментов и механизмов, вкратце расскажу о них и дам ссылки для детального изучения.
Итак, что же ты мог упустить при работе с Nx:
• nx run-many
• dependency graph + nx affected
• nx-enforce-module-boundaries es-linting
• computation cache
• nx cloud
• buildable libs
Привет! Меня зовут Даниил, я фронтенд-разработчик в Тинькофф Бизнесе. Мы строим удобные интерфейсы, чтобы клиенты могли быстро зарегистрировать бизнес.
Сегодня я хочу рассказать, почему мы используем Nx для всех наших Angular-проектов, какие проблемы решает этот инструмент и чем он лучше Angular CLI.
Для разработчиков построение масштабируемых и поддерживаемых приложений может быть значительным вызовом, особенно при работе с большими кодовыми базами и несколькими сервисами. К счастью, использование подхода монорепозитория в сочетании с мощными инструментами, такими как NX, Lerna и Yarn, может обеспечить упрощенный процесс разработки, который повышает общность кода и возможность повторного использования.
Это подробное руководство нацелено на помощь разработчикам в настройке монорепозитория с использованием NX, Lerna и Yarn. Руководство включает подробную информацию о начальной настройке, структуре каталогов, управлении зависимостями, тестировании и развёртывании.
После освоения туториала разработчик получат полное понимание того, как создавать масштабируемые и поддерживаемые приложения, используя подход монорепозитория. Он также получит знания о необходимых инструментах и знаниях для перехода на новый уровень разработки. Давайте приступим!
С распространением практики доставки непрерывных обновлений время сборки приложений стало критически важным параметром как для разработчиков, так и для бизнеса компании в целом. В данной статье описан мой опыт ускорения Frontend пайплайна Jenkins в Kubernetes на базе yarn и nx
Спустя несколько лет промышленной разработки приложений на javascript, решил вспомнить молодость и сделать небольшой pet-проект, который в полной мере развернул весь процесс разработки подобного рода приложений с использованием фреймворка Angular. В статье делюсь своими впечатлениями, а также пытаюсь понять, стоит ли делать сайты визитки на Angular.
Обзорная статья, посвященная использованию инструментария Nx для разработки современных веб приложений с применением лучших практик. В статье приводится обзор возможностей Nx, а также приведены примеры создания различных библиотек и приложений для всевозможных нужд фронденд разработчика.
Как все знают, монорепозиторий - это несколько частей проекта (приложения, сервисы, библиотеки и т.д.), которые хранятся в одном репозитории. Плохо это или хорошо - не тема данной публикации. Но все же упомяну некоторые причины по которым я решил их использовать.
В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.
В определенных случаях среди нескольких сервисов, можно выделить общий код, который можно переиспользовать (описание интерфейсов, утилиты и т.д.) и особенно важно на самом старте проекта, когда эти общие куски кода только формируются не тратить время на коммиты в отдельные репозитории, если нужно всего лишь добавить поле в общий интерфейс.
После того как мы перешли на монорепозиторий появилось еще несколько преимуществ, без которых, в принципе, тоже можно жить, но все равно это был приятный бонус.
И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?
