Привет и спасибо за вопрос! Циклические зависимости начали образовываться после переезда в монорепозиторий и выносе переиспользуемых утилит в shared пакеты для избавления от дублирования кода которое существовало при работе в разных репозиториях, а избавились от них более детально изучив зависимости и настроив линтер на прикрепленное мной правило
Флоу в ui, как вы верно подметили, для минорных изменений стал действительно проще и изменяется в одном месте, раскатываясь на все связанные приложения. Для критичных изменений создаются и тестируются ветки от ломающих коммитов с фиксами всего или по доменам, после сливаются в один МР и едут в мастер сразу со всеми актуальными изменениями и обновлениями в приложениях
Согласен по поводу новых проектов на vite, ждём релиз 8 версии чтобы тестить его для большего числа проектов. Как показывает практика - даже крупные инструменты и утилиты уже сменили стандартный сборщик на vite и предлагают его же в качестве бандлера использовать остальным. Но совсем списывать со счетов webpack тоже не стоит, всё же он имеет место быть там где не хочется ничего менять или где нужно предсказуемое поведение всегда и без магии, так что не обижайте старичка!
Супер результаты и спасибо что поделились! Мы активно на самом деле ищем возможности ускорения и одной из них как раз является Rspack, но он, к сожалению, пока нестабильно себя показывает даже в деве с микрофронтами в монорепозитории из-за чего миграция застряла, но процесс идёт :)
Привет, отвечу на твои вопросы 1. В приведенном примере указан базовый конфиг только для стилистических правил stylistic, которые касаются непосредственно оформления - пробелов, кавычек и т.д. Если предпочитаете шаблонные строки конкатенации - можете использовать это правило из стандартного ESLint и тогда всё будет именно так как вам хочется) 2. Замеры скорости отдельно взятых инструментов проводить нет особого смысла просто потому что они разные и у них разный принцип действия. Простой конфиг с запуском Prettier будет всегда быстрее ESLint даже с набором из 4-5 правил, так как он не анализирует код, а просто его переписывает. Вот статья в которой приведён пример сравнения перфоманса этих инструментов и, естественным образом, Prettier в ~5 раз быстрее ESLint. Посыл статьи скорее в том что если в проекте используется ESLint, то использовать дополнительно Prettier может быть лишним, т.к. можно ограничиться запуском только одного инструмента, который будет работать чаще всего быстрее, чем два. 3. Это не отменяет необходимость использования дополнительных пакетов и плагинов типа eslint-plugin-prettier которые используют Prettier как правила ESLint и сводят весь перфоманс на нет. Плюс ко всему появляется отдельный конфиг с возможностью использования отдельного инструмента - зачем если пользоваться унифицированным решением проще и дешевле, но это, конечно, моё мнение и я тоже могу ошибаться
Формально всё работает на JS и мы пишем TS который транспилируется, styled components которые тоже прям в JS'e ну и ESLint сам запускается на node. Так что слава джаваскрипту!
Вместо этого плагина для prettier, вы можете использовать eslint-plugin-import, для ESLint, если угодно, там можно настроить и линтинг сортировки импортов
Эта табличка нужна исключительно для наглядного примера (в целом не далёкого от правды), который в чуть более доступной форме отражает возможности представленных инструментов. Для более точных цифр лучше посмотреть на исследования скорости с тестами, примеры которых я тоже прикрепил на всякий случай.
Привет! Благодарю за вопрос, насколько мне известно "из коробки" vite не поддерживает мультитред сборку (rollup), но в таком режиме может работать esbuild, который в vite только для dev, но можно попробовать полностью перейти на esbuild. Если сборку надо производить не в огромном монолите, а просто несколько пакетов, то можно попробовать запускать просто несколько скриптов сборки одновременно, но качество логов оставит желать лучшего) Webpack так же из коробки многопоточно не работает, но у него много разных плагинов, можно так же посмотреть в сторону esbuild-loader / thread-loader для ускорения сборки
Привет! Спасибо за комментарий, тесты для этой таблицы генерил DeepSeek, но предположительно под зависимостью понимаются устанавливаемые пакеты из package.json
Привет и спасибо за вопрос! Циклические зависимости начали образовываться после переезда в монорепозиторий и выносе переиспользуемых утилит в shared пакеты для избавления от дублирования кода которое существовало при работе в разных репозиториях, а избавились от них более детально изучив зависимости и настроив линтер на прикрепленное мной правило
Флоу в ui, как вы верно подметили, для минорных изменений стал действительно проще и изменяется в одном месте, раскатываясь на все связанные приложения. Для критичных изменений создаются и тестируются ветки от ломающих коммитов с фиксами всего или по доменам, после сливаются в один МР и едут в мастер сразу со всеми актуальными изменениями и обновлениями в приложениях
Согласен по поводу новых проектов на vite, ждём релиз 8 версии чтобы тестить его для большего числа проектов. Как показывает практика - даже крупные инструменты и утилиты уже сменили стандартный сборщик на vite и предлагают его же в качестве бандлера использовать остальным. Но совсем списывать со счетов webpack тоже не стоит, всё же он имеет место быть там где не хочется ничего менять или где нужно предсказуемое поведение всегда и без магии, так что не обижайте старичка!
Супер результаты и спасибо что поделились! Мы активно на самом деле ищем возможности ускорения и одной из них как раз является Rspack, но он, к сожалению, пока нестабильно себя показывает даже в деве с микрофронтами в монорепозитории из-за чего миграция застряла, но процесс идёт :)
Спасибо за отзыв, круто, что перформанс стал лучше!
Привет, отвечу на твои вопросы
1. В приведенном примере указан базовый конфиг только для стилистических правил stylistic, которые касаются непосредственно оформления - пробелов, кавычек и т.д. Если предпочитаете шаблонные строки конкатенации - можете использовать это правило из стандартного ESLint и тогда всё будет именно так как вам хочется)
2. Замеры скорости отдельно взятых инструментов проводить нет особого смысла просто потому что они разные и у них разный принцип действия. Простой конфиг с запуском Prettier будет всегда быстрее ESLint даже с набором из 4-5 правил, так как он не анализирует код, а просто его переписывает. Вот статья в которой приведён пример сравнения перфоманса этих инструментов и, естественным образом, Prettier в ~5 раз быстрее ESLint. Посыл статьи скорее в том что если в проекте используется ESLint, то использовать дополнительно Prettier может быть лишним, т.к. можно ограничиться запуском только одного инструмента, который будет работать чаще всего быстрее, чем два.
3. Это не отменяет необходимость использования дополнительных пакетов и плагинов типа
eslint-plugin-prettierкоторые используют Prettier как правила ESLint и сводят весь перфоманс на нет. Плюс ко всему появляется отдельный конфиг с возможностью использования отдельного инструмента - зачем если пользоваться унифицированным решением проще и дешевле, но это, конечно, моё мнение и я тоже могу ошибатьсяДа, есть опыт использования
Формально всё работает на JS и мы пишем TS который транспилируется, styled components которые тоже прям в JS'e ну и ESLint сам запускается на node. Так что слава джаваскрипту!
Вместо этого плагина для prettier, вы можете использовать eslint-plugin-import, для ESLint, если угодно, там можно настроить и линтинг сортировки импортов
Эта табличка нужна исключительно для наглядного примера (в целом не далёкого от правды), который в чуть более доступной форме отражает возможности представленных инструментов. Для более точных цифр лучше посмотреть на исследования скорости с тестами, примеры которых я тоже прикрепил на всякий случай.
Привет! Спасибо за комментарий, действительно рекомендаций непосредственно по сборке тут не найти, исправил в названии
Привет! Спасибо за интересный кейс, если удастся разобрать, то допишу здесь!
Привет! Благодарю за вопрос, насколько мне известно "из коробки" vite не поддерживает мультитред сборку (rollup), но в таком режиме может работать esbuild, который в vite только для dev, но можно попробовать полностью перейти на esbuild. Если сборку надо производить не в огромном монолите, а просто несколько пакетов, то можно попробовать запускать просто несколько скриптов сборки одновременно, но качество логов оставит желать лучшего) Webpack так же из коробки многопоточно не работает, но у него много разных плагинов, можно так же посмотреть в сторону esbuild-loader / thread-loader для ускорения сборки
Привет! Спасибо за комментарий, тесты для этой таблицы генерил DeepSeek, но предположительно под зависимостью понимаются устанавливаемые пакеты из package.json