Установка frontend зависимостей

[someApprentice]

В данный момент все frontend зависимости расположенны в репозитории. Нужно придумать как лучше получать их при установке приложения.

#21 (comment)

Осталось разобраться с вендорными файлами (42 МБ шрифтов в репозитории это не норм), что ещё? Ставим фронтенд зависимости через Composer и копируем скриптом только нужное в public/vendor.

А также, необходимо сделать сброс кэша браузере при обновлении frontend кода.

https://symfony.com/doc/current/frontend/encore/versioning.html

[kubk]

@someApprentice @codedokode @foobar1643 Не могу вспомнить, зачем копировать вендорные JS/CSS файлы композер-скриптом в публичную папку, если можно отдать через CDN?
Считаю, что настраивать сборщик для этого приложения нет необходимости. Для борьбы с кешем можно использовать GET-параметр, тут это очень редкая операция и нет ничего зазорного в том, чтобы сделать это вручную. Изменения в JS/CSS файлах сейчас применяются после перезагрузки страницы без необходимости включать вотчер сборщика. Вебпак может предоставить улучшенный developer-experience за счёт hot module replacement - страница будет обновляться точечно без перезагрузки. Но на наших масштабах это стрельба из пушки по воробьям.

[codedokode]

@kubk Речь выше шла не про сборщик и не про CDN, а про установку фронтенд-библиотек менеджером пакетов (композер, npm или bower) и копирование их в публичную папку. Если менеджер пакетов позволяет ставить библиотеки сразу в публичную папку, то копировать не требуется.

Имхо, CDN для крошечного сайта с крошечным трафиком даром не нужен и будет лишь усложнением и лишней точкой отказа. Более того, я вообще не уверен, что от CDN будет какой-то заметный эффект, если большинство пользователей из СНГ, и оптимизировать загрузку для пользователей где-то в Австралии не требуется. Ну и даже при наличии CDN, CDN ведь обычно берет файлы с сайта, так что они все равно должны быть где-то выложены.

Копируют файлы в случае, если они ставятся композером в папку vendor, которая не доступна публично. Также, вместо копирования под линуксом можно просто сделать симлинк из публичной папки на папку vendor, например, public/vendor/lib -> vendor/lib, так делают в Симфони.

Для борьбы с кешем можно использовать GET-параметр

Бороться с кешем надо только если на сервере отдается заголовок Expires, а можно его не отдавать. Если же хочется использовать Expires, то если есть скрипт деплоя, можно еще при деплое в файлик сохранять хеш последнего коммита (или дату коммита) и использовать его в качестве параметра. А еще можно не включать кеширование по Expires вообще, там не такой трафик, чтобы заморачиваться с оптимизацией, без Expires браузер будет слать запрос с If-Modified-Since, и получать ответ с кодом 304, трафик в принципе все равно экономится.

Вручную менять параметр в URL не стоит, но можно сделать функцию, через которую пропускается URL перед выводом. Она может сейчас ничего не делать, а в будущем, если надо, будет подставлять в него параметр для борьбы с кешированием:

<link rel="stylesheet" href="{{ asset_url('css/style.css') }}">

Вебпак может предоставить улучшенный developer-experience за счёт hot module replacement - страница будет обновляться точечно без перезагрузки.

А по моему, это будет ухудшенный developer-experience.

Я негативно отношусь к таким вещам, так как оптимизация (склеивание файлов) если и делается, то для продакшена. В dev-среде она не нужна (зачем? трафик на локалхосте экономить?), как и не нужен вебпак. Но на практике, все его почему-то используют, и героически придумывают решение проблемы (отслеживание изменений в файлах, hot reload), которой изначально и не было, а потом появляется проблема отображения исходного кода, и они начинают мучаться с source maps, которые работают через раз (а в Фаерфоксе работают плохо) и мешают отладке. В dev-среде можно ведь ничего не склеивать, а просто подключать оригинальные файлы.

Более того, я не очень понял, как hot reload связан с вебпаком. Разве оно не само по себе работает?

[kubk]

@codedokode В описании issue есть ссылка на webpack encore, поэтому я упомянул webpack. Вопрос такой - зачем писать скрипты по копированию вендорных файлов в публичную папку, если можно просто подключить эти файлы через CDN: <script src="//cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>. Не помню, чтобы такие CDN когда-то отваливались. Composer вроде не умеет устанавливать сразу в публичную папку. Я писал такие bash-скрипты и использовал символические ссылки.

Hot module replacement и hot reload - это разные вещи. HMR - это замена JS модулей сборщиком без перезагрузки страницы. Пример с гифкой: https://github.com/kubk/angular-ngrx-hmr
Тут состояние приложения не сбрасывается после обновления файла. HMR экономит время на разработку SPA, когда до определённого состояния приложения нужно докликать.
Hot reload - перезагрузка страницы в ответ на изменения в файлах.
Я привёл аргумент в пользу вебпака чтобы не выглядело так, будто я совсем против сборщиков. В этом приложении можно обойтись без сборщика.

Вручную менять параметр в URL не стоит, но можно сделать функцию, через которую пропускается URL перед выводом.

Спасибо, хороший вариант, но у нас изменения на фронте делаются раз в пару лет. В будущем тоже не вижу много причин для изменений.