Хабрадевелоперам, привет! Не так давно мы начали разрабатывать комплексный проект, у которого есть или планируется несколько видов фронт-енда, множество сервисов бэк-енда, интерфейс командной строки, демоны и много ещё чего. У всего этого в свою очередь есть шареный код, а совершенно новые приложения должно быть возможным собирать из имеющихся кирпичиков простым и понятным образом.

Если не занудствовать с терминологией, мы делаем платформу. Платформу для визуального программирования под DIY-электронику.

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

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Как вы помните из предыдущих частей (1, 2, 3), у нас уже есть функциональность для работы с планировщиком в бэкенде. Теперь нашей задачей будет создать удобный и интуитивно понятный пользовательский интерфейс, чтобы пользователи могли легко взаимодействовать с задачами.

Работая с монорепозиторием, ты наверняка слышал о наборе инструментов 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.

Практический урок по написанию собственного плагина, на примере react приложения.

Перевод статьи подготовлен для студентов курса «DevOps практики и инструменты» в образовательном проекте OTUS.

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

13 октября состоялся релиз npm@7.0.0. Релиз носит экспериментальный характер и доступен для скачивания из публичного npm-реестра с тегом next-7. Также npm 7 поставляется вместе с node.js 15.

Как вы помните, нечетные версии node.js тоже скорее являются нестабильными предрелизами. Только четные версии получают статус LTS и рекомендуются для использования в продакшене. Но сейчас мы поговорим исключительно об npm, а если быть более точным, то разговор пойдет о нескольких очень ожидаемых фичах, вошедших в свежий релиз.

О чём пойдёт речь?

Пилотный пост будет посвящён интересной проблеме с которой мы столкнулись при попытке организовать CI/CD для монорепозитория с lerna. Сразу скажу, что этот пост:

* не про монорепозитории. Плюсы и минусы монорепы, как концепции, уже давно описаны в множестве постов, в том числе на Хабре (этот довольно холиварный, кстати)

* не про инструменты для управления монорепозиториями. Монорепу можно реализовать при помощи Nx, rush, даже просто yarn workspace. Но так получилось, что мы выбрали lerna и поживём с ней какое то время.

* не про пакетные менеджеры. Могу порекомендовать хороший видос со сравнением npm, yarn и pnpm и офигенную серию постов в которой работа npm объясняется с самых азов и очень тщательно. У нас npm (пока)...

* не про nestjs. Но он классный!

Обо всём этом будет рассказано только в том объёме, который нужен для понимания проблематики.

Тогда о чём? О том, как сварить это всё вместе.

Как все знают, монорепозиторий - это несколько частей проекта (приложения, сервисы, библиотеки и т.д.), которые хранятся в одном репозитории. Плохо это или хорошо - не тема данной публикации. Но все же упомяну некоторые причины по которым я решил их использовать.

В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.

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

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

И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?

Некоторое время назад «Лаборатория Касперского» решила перенести свои проекты по разработке в монорепозиторий с общей инфраструктурой. Мы решили поделиться опытом и рассказать, с какими проблемами сталкиваются разработчики в выбранном подходе, и как мы научились их решать.

Существуют разные способы создания монорепозитория в node.js, есть разные библиотеки для этих целей: yarn workspaces, lerna и так далее. Но сегодня я хочу коротко рассказать о монорепозитории на typescript, используя только npm.

Дано

1. Монорепозиторий на базе Lerna и Yarn workspaces.
2. Десяток приложений, и десятки общих пакетов на TypeScript, Angular, NodeJS.
3. Высокое покрытие тестами самых разных мастей (модульные, интеграционные, e2e).
4. и Atlassian Bamboo CI/CD.

Задача

Ускорить имеющиеся пайплайны в 2 раза (до, хотя бы, получаса). Попутно повысив стабильность до 90%.

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

Всем привет! Меня зовут Илья и я хочу рассказать вам как можно подробнее про Angular Libs. В частности, то, как можно использовать его в качестве монорепозитория для сборки нескольких приложений с tree-shaking и переиспользуемостью различных модулей в разных библиотеках и частях системы.

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

В этом посте хочу продолжить тему разделения функционала на библиотеки и, как апофеоз, рассказать о сборке двух, похожих визуально, но разных по функциональности приложений из одного набора библиотек. А так же осветить механизм работы tree shaking при использовании Angular Libs.

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В серии статей мы поэтапно разработаем продвинутое приложение-планировщик. Сначала создадим и настроим монорепозиторий c помощью NX, разработаем интерфейс с помощью React, добавим backend на основе NestJS, и, наконец, подключим базу данных MongoDB.

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

Меня зовут Игорь Кацуба, я лид Core команды в Tinkoff Business. Поделюсь своим опытом, расскажу какие этапы развития нам приходится проходить, чтобы получить результат и что мешает двигаться дальше. А также узнаем про принцип цикличности, на котором и основаны все этапы. Поехали…

Делиться своими идеями с сообществом - хорошо и правильно. Это позволяет развиваться, перенимать лучшие практики, исследовать новые инструменты, учиться оформлять свои решения. Но какой код стоит выносить в общий доступ? И как делать это на постоянной основе? Чтобы разобраться в этих вопросах я решил сделать свой Javascript OpenSource Boilerplate - маленькую, но максимально расширяемую библиотеку компонентов. Она называется handy-ones.

В прошлой статье я рассказывал про библиотеку компонентов и утилит handy-ones. Я задумал её не только чтобы делиться с сообществом своими наработками на постоянной основе, но главное - чтобы понять, как должен выглядеть, собираться, тестироваться и дистрибутироваться современный JavaScript-проект.

Состоялся релиз Lerna 6!!! В статье собрано все, что вы должны знать о новом опыте, который предлагает Lerna!

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

Когда мы получили управление над Lerna начались настоящие американские горки. Мы запустили совершенно новый сайт, обновили документацию и сделали Lerna в 10 раз быстрее. И вот, Lerna 6 вышла!