SUPER_OLEG_DEV Telegram 222
И раз уж зашел разговор о CLI, поделюсь одной из актуальных задач - разработка обновленной @tramvai/cli (уже писал про это короткий пост)

Во вложении - дизайн новой CLI, он уже претерпел ряд изменений, но основные концепции остались.

Какие основные цели для новой CLI:
- решить базовые проблемы с перформансом - основная, webpack MultiCompiler запускает все сборки в одном процессе, серверная и клиентская конкурируют между собой
- реализовать удобную систему плагинов (и первым же новым плагином интегрировать rspack)
- полностью разделить JS API и CLI API
- сделать общий набор тест-кейсов, который будет удобно запустить с разными плагинами - вебпак+бабель, вебпак+swc, rspack
- избавиться от легаси, улучшить отладку, упростить структуру

Итак, основная техническая задачка тут - ускорение двух параллельных вебпак сборок.

Тут очевидное решение - вынести их в worker_threads, что из коробки webpack и его MultiCompiler не умеет.

И главный челлендж тут - как передать конфигурацию из CLI в воркеры, если там могут быть плагины - то есть не сериализуемые методы/классы/прочие объекты?

Этот кейс решил следующим образом:
- есть общая логика - чтение tramvai.config.ts конфигурационного файла, где могут быть плагины
- есть набор входящих сериализуемых параметров, которые можно передать через CLI (`tramvai start ...`) или JS API (`new Tramvai().start(...)`)
- и основной процесс и webpack воркер - считывают один и тот же конфигурационный файл
- входящие параметры пробрасываются при старте воркера из основного процесса

Вокруг воркеров сделал небольшие удобные обертки для контроля и коммуникации.

Основной пакет @tramvai/api определяет базовые интерфейсы - DevServer и Builder, ждет их в DI контейнере, и запускает их жизненный цикл.

Вся логика с webpack, реализация DevServer на основе webpack-dev-middleware и соответствующие зависимости - в отдельном @tramvai/cli-plugin-webpack плагине, аналогичный будет для rspack.

Все babel зависимости и фабрика babel конфига - в отдельном @tramvai/cli-plugin-babel, и соответственно такой же будет для swc.

Набор тестов сделан как фабрика, под разные плагины но с общими кейсами и фикстурами.
Стараюсь добавлять тест-кейс на каждый значимый параметр сборки, который мы явно конфигурируем.

Похоже основным челленджем далее будет - миграция пользователей и временная поддержка двух реализация команды tramvai start.
🔥5👍2



tgoop.com/super_oleg_dev/222
Create:
Last Update:

И раз уж зашел разговор о CLI, поделюсь одной из актуальных задач - разработка обновленной @tramvai/cli (уже писал про это короткий пост)

Во вложении - дизайн новой CLI, он уже претерпел ряд изменений, но основные концепции остались.

Какие основные цели для новой CLI:
- решить базовые проблемы с перформансом - основная, webpack MultiCompiler запускает все сборки в одном процессе, серверная и клиентская конкурируют между собой
- реализовать удобную систему плагинов (и первым же новым плагином интегрировать rspack)
- полностью разделить JS API и CLI API
- сделать общий набор тест-кейсов, который будет удобно запустить с разными плагинами - вебпак+бабель, вебпак+swc, rspack
- избавиться от легаси, улучшить отладку, упростить структуру

Итак, основная техническая задачка тут - ускорение двух параллельных вебпак сборок.

Тут очевидное решение - вынести их в worker_threads, что из коробки webpack и его MultiCompiler не умеет.

И главный челлендж тут - как передать конфигурацию из CLI в воркеры, если там могут быть плагины - то есть не сериализуемые методы/классы/прочие объекты?

Этот кейс решил следующим образом:
- есть общая логика - чтение tramvai.config.ts конфигурационного файла, где могут быть плагины
- есть набор входящих сериализуемых параметров, которые можно передать через CLI (`tramvai start ...`) или JS API (`new Tramvai().start(...)`)
- и основной процесс и webpack воркер - считывают один и тот же конфигурационный файл
- входящие параметры пробрасываются при старте воркера из основного процесса

Вокруг воркеров сделал небольшие удобные обертки для контроля и коммуникации.

Основной пакет @tramvai/api определяет базовые интерфейсы - DevServer и Builder, ждет их в DI контейнере, и запускает их жизненный цикл.

Вся логика с webpack, реализация DevServer на основе webpack-dev-middleware и соответствующие зависимости - в отдельном @tramvai/cli-plugin-webpack плагине, аналогичный будет для rspack.

Все babel зависимости и фабрика babel конфига - в отдельном @tramvai/cli-plugin-babel, и соответственно такой же будет для swc.

Набор тестов сделан как фабрика, под разные плагины но с общими кейсами и фикстурами.
Стараюсь добавлять тест-кейс на каждый значимый параметр сборки, который мы явно конфигурируем.

Похоже основным челленджем далее будет - миграция пользователей и временная поддержка двух реализация команды tramvai start.

BY SuperOleg dev notes




Share with your friend now:
tgoop.com/super_oleg_dev/222

View MORE
Open in Telegram


Telegram News

Date: |

Step-by-step tutorial on desktop: Public channels are public to the internet, regardless of whether or not they are subscribed. A public channel is displayed in search results and has a short address (link). With the administration mulling over limiting access to doxxing groups, a prominent Telegram doxxing group apparently went on a "revenge spree." A new window will come up. Enter your channel name and bio. (See the character limits above.) Click “Create.” How to Create a Private or Public Channel on Telegram?
from us


Telegram SuperOleg dev notes
FROM American