Я знаю как работает кэширование и что в цепочке обработки http запроса за что отвечает) Я вроде не просил это объяснять

а эта группа для вас только?)

Так а зачем вы тогда меня реплаили?)

Написали бы тогда всем, а не мне)

если у вас классический спа вам не нужен дополнительный бекенд который будет из манифеста ижектить ресурсы

вы в таком случае недоразобрались и навелосипедили оверхеда

потому что это коментарий к вашему сообщению

А вы знаете, как у меня работает приложение?)

И что оно работает на симфони, который генерит ассеты через манифест?)

вы утверждаете что вот так
https://t.me/webpack_ru/79680

Покажите, где я это утверждал

Я здесь писал про подход  'css/[name].css?[contenthash:8]' и 'css/[name].[contenthash:8].css'.

Там нет ни слова о том как у меня строится отдача статики

никто не знает как у вас настроена отдача статики поэтому с вашего позволения я опишу это с в контексте того как она работает в у большинства

Пожалуйста, уступаю микрофон

У большинства в результате билда получается набор статических файлов названия которых записываются к index.html в процессе сборки.
В этом контексте разница между тем хеш будет в названии файла или после него (т.е. как параметр запроса) имеют следующую разницу:
Статический сервер считает одинаковыми (ведущими на тот же файл) ссылки ./foo/bar/bundle.js?12345 и ./foo/bar/bundle.js?54321,
что на практике означает что если браузер запросит bundle.js?12345  ему без зазрения совести обычный статический сервер отдаст bundle.js?54321 что с высокой долей вероятности приведет к очень загодчным крашам приложения. В случае если мы запишем хеш в название бандла - браузер получит 404 ошибку, что, в зависимости от ситуации либо позволит нам ее отловить и обновить страничку и кода, ну или хотябы бы сразу увидеть что стало причиной падения. Так же стоит заметить что хеш после ? имеет свой юзкейс - представим ситуацию что наше приложение при загрузке запрашивает некторый config.json и мы не хотим его кэшировать никогда. Вот тут хеш после ? нам очень поможет так как с точки зрения браузерного кэша config.json?1234 и config.json?4321 это совсем разные файлы даже если физически будет возращается один и тот же config.json

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

> Потому что в этом случае, если изменилась любая из зависимостей, это поменяет хэш ее чанка

это справедливо только для hash но к счастью у нас есть contenthash который не страдает этой проблемой

После того как все такие пути вынесены в одно место, идентификаторы чанков (уже не пути) внутри чанков перестают меняться при любом чихе