runtime‑сборка пошла жёстко не по плану

в общем, с runtime-сборкой всё пошло жестко не по плану. esbuild завёлся с полпинка, и рендеринг runtime-скомпилированного react-компонента у меня был готов ещё часа 4 назад.

казалось бы, что может пойти не так, остаётся ведь всего лишь генерить tailwind-стили? дело в том, что tailwind v4 использует module resolution без указания main в package.json, что ломает сборку pkg (утилиты, которая делает single-binary executable с Node.js).

решил завести tailwind v4 в браузерной среде. сборка с tailwind состоит из 4 частей: 1. базовая компиляция css-файла (того самого, который `@import 'tailwindcss';`) 2. парсинг всех исходников проекта в поисках строк, которые выглядят как tailwind utility классы (типа md:text-xs в коде вашего компонента). эти строки называются "кандидаты". 3. далее, tailwind фильтрует кандидатов, оставляя только валидные utility-классы. он компилирует изначальный css + все utility-классы, которые он нашёл у вас в исходниках. на выходе получается intermediary css. 4. далее, tailwind швыряет intermediary css в lightningcss, и тот уже превращает его в финальный css файл.

так вот, пункт 2 делается через @tailwind/oxide - Rust-тула, который очень быстро сканирует код вашего проекта. и он не только не opensource, но и не имеет wasm-версии для браузерной среды. пункт 4 делается через lightningcss - тоже Rust-based тулы, но у неё, к счастью, есть wasm-версия. в целом, пункт 2 можно заменить на utility classes extractor из tailwind v3, и оно будет работать.

но мне показалось это лютой грязью, и я захотел перейти на tailwind v3. но вот беда - shadcn перешёл на tailwind v4 довольно плотно, и legacy-доки никто не обновляет, и написана там дичь. установить shadcn-компоненты для tailwind v3 - задачка довольно нетривиальная.

в общем, похоже, придется таки заводить tailwind v4 с extractor'от tailwind v3 в браузер. и тут возникает вопрос... а зачем тогда мне вообще будет нужен Node.js? мб избавлюсь от него, сборка станет ещё легче.