Как стать автором
Обновить

Комментарии 5

А как в ts настроить вывод стилей при сборке библиотеки, например, какого нибудь компонента? Что будет, если 10 проектов и 10 библиотек поддерживать потребуется? Настроить pipeline для каждого проекта не будет болью?

В самой библиотеке стилей нет. Библиотека по сути делает сборку заданного проекта, используя вебпак, конфиг которого содержится в самой библиотеке, то есть разработчику задавать его не нужно (хотя можно сделать возможность доп. конфигурации, как, например, в nextjs). В этом конфиге уже содержатся нужные лоадеры для стилей, картинок, шрифтов и тд. Поэтому когда собирается проект, все ассеты соберутся автоматически.

По поводу поддержки 10 проектов не совсем понял. Библиотека ставится как зависимость npm-пакетом в любой проект и дальше используется для его разработки, сборки, запуска и тд.
Возможно, вы имели ввиду что конкретно при разработке самой библиотеки тестовый проект находится в одном репозитории с библиотекой? Это сделано просто для удобства разработки самой библиотеки, чтобы ее можно было сразу же пробовать на тестовом проекте. А дальше, уже после публикации в npm-репозиторий, библиотеку можно просто установить в любой проект и сразу использовать.

Фронтенд-фреймворк для сервер-сайд рендера, колесо сансары дало оборот.
Судя по всему HTML over WebSocket и уход логики с фронта — тренд грядущего десятилетия.

Логика с фронта никуда не девается, а вот рендер на сервере может быть полезен для seo или при оптимизациях первого взаимодействия с сервисом, ведь контент уже будет отрендерен и пользователь быстрее его увидит.

Но в целом конечно уйти от классических MVC фреймворков с рендером шаблонов в сторону SPA приложений, чтобы потом эти SPA приложения рендерить на сервере, это сильно, согласен :)

Но такой вот современный фронтенд, ничего не поделаешь)

SSR — вынужденная мера, и не стоит тут фронтендеров винить. Он решает 2 проблемы — индексация поисковиками и быстрая поставка готовой разметки. Первая проблема может решиться улучшением поисковых движков, вторая — либо уменьшением размера JS кода, либо статичным пререндеренгом, либо динамическим (SSR). Последний способ решает и первую и вторую проблемы, хотя требует довольно большой возни. Так что да, не мы такие — жизнь такая.


В тексте статьи у вас увидел parallel-webpack, сейчас бы я не стал его рекомендовать — там накопилось довольно много багов и репозиторий заброшен, проще написать свое решение типа такого webpack-parallel-simple

Зарегистрируйтесь на Хабре, чтобы оставить комментарий