Почему с nx на turbo? Первый был для меня не удобен во многих мелочах, особенно в расширении для vscode на которое я возлагал большие надежды. Это еще терпимо, но я ни раз сталкивался с какими-то ошибками: какие-то заводил, какие-то просто не понимал как дебажить, воспроизводить и репортить - падает ошибка при запуске билда с графом на десяток пакетов, а откуда и почему не ясно.
На турбо оказалось норм, он меньше дает, но и попроще как-то - я это ценю.
По ссылке выше ишье как раз на багу в кодгене. Меня это напрягало, но было терпимо потому что сам формат был удобный - заводишь папку с кучкой файлов в которых просто специальным синтаксисом указываешь ключевые слова для изменения. В итоге, можно самому просто копирнуть папку и глобальным реплейсом за 5 секунд персонализировать темплейт в пакет. Удобно. Но как автоматизировать это другими инструментами, после миграции на турбо, я не нашел. Все говорят про plop, но он как будто заточен на кодснипеты. У меня простая задача - скопирнуть папку и сделать глобал реплейс.
Решил не привносить доп пакеты с доп сложностью, а написать свой скрипт - вышло достаточно коротко и внятно кмк.
С публикацией пакетов такая проблема: их много и следить за тем что изменилось очень тяжело, а как паблишить автоматически из CI я ещё не разобрался и не уверен можно ли вообще - у меня юбикей для OTP. Хотелось инструмент который может просто подсказать какие пакеты не актуальны в нпм. Я уже давно использовал npmjs.com/package/@jsdevtools/npm-publish и вроде норм, хотя оказалась что он не читает publishConfig.tag из пакаджисона - можно было бы запулреквестить, но я заметил что версию пакета он получает простой командой
npm view package-name version и взяв тот же zx запили свой скрипт, избавив нодмодули от лишнего веса.В общем, я доволен тем что сейчас так просто можно пилить свои небольшие скрипты и std ноды достаточно богато, а где его не хватает можно использовать простой концептуально zx.