Comments 2
Почему такие вещи как создание шаблонного кода или же выполнение команд должны реализовываться как nx-плагины?
Приведенные вами примеры, можно прекрасно реализовать как скрипты на ts-node или deno, тем самым снизить зависимость от nx. Потому что при обновлении версии nx или же отказе от него все это может сломаться и его долго и больно надо чинить. А если это скрипт на deno то достаточно просто скопировать ts-файл в другой проект и даже не надо будет устанавливать пакеты, так как можно использовать импорты с url на конкретную версию.
nx предлагает свои подходы в разработке. Нет смысла брать nx, если у тебя нет микрофронтов. Он просто упрощает взаимодействие, предлагает общие подходы и готовые плагины.
А тут приведенные примеры для того чтобы просто показать как писать для nx. я с вами согласен, что подобный пример лучше реализовывать на простых инструментах.
Мы выбрали nx для того чтобы работать с микрофронтами проще, чтобы процессы ci/cd работали из коробки. А свое плагины и генераторы в проектах это уже второстепенно. Зато они позволяют скрыть реализацию и настроить один раз окружение webpack и в каждом микрофронте не повторяться, просто ссылаться на общий executor. Или вызывать общий generator для всех. На проектах где используется yarn, придется самим писать очень много кода для того, чтобы были подобные плагины, которые есть в nx.
Разработка собственного плагина для nx (executor и generator)