Vite::asset() и asset() в Laravel: В чём разница и как организовать файлы?

Введение

Когда вы начинаете разрабатывать на Laravel, часто возникает вопрос: куда складывать файлы приложения и как к ним правильно обращаться? Вы можете заметить, что в шаблонах используются разные хелперы – asset() и Vite::asset(). Почему нельзя использовать один универсальный метод? Где лучше хранить картинки и стили?

Давайте разберёмся в этих вопросах и посмотрим на типовой подход к хранению статических и динамических файлов в Laravel, а также на то, как их выдавать конечному пользователю.

Почему вообще нужно разделять файлы?

В современном вебе есть разные типы ресурсов:

1. Статические (дизайнерские) активы – логотипы, иконки, файлы стилей, скрипты, фоны, изображения интерфейса, которые связаны с дизайном и не меняются на лету.
2. Динамические файлы – загружаемые пользователями картинки, документы, или любые другие данные, которые могут регулярно меняться.

В Laravel принято разделять эти две группы файлов, потому что:

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

asset() и Vite::asset(): в чём разница?

• asset('...') – стандартный Laravel-хелпер. Преобразует путь, переданный внутрь, в корректный URL к публично доступному каталогу приложения. По умолчанию, в Laravel настроен симлинк public/storage → storage/app/public, поэтому любой файл, находящийся в storage/app/public, можно получить по адресу https://ваш-домен/storage/....

  Пример в Blade-шаблоне:

  <img src="{{ asset('storage/contacts/3.jpg') }}" alt="Avatar">
  

  Этот код сгенерирует URL вида:

  https://ваш-домен/storage/contacts/3.jpg
  

• Vite::asset('...') – часть интеграции Laravel с Vite. Если в вашем проекте настроен Vite, то вместо Mix (или Webpack) вы собираете ваши фронтенд-активы через него.
  При разработке, когда запущен Vite Dev Server, Vite::asset() может вернуть ссылку на «горячий» (hot-reload) сервер. При продакшен-сборке – версию файла с хешем. То есть, если у вас есть logo.png внутри resources/, Vite может сгенерировать что-то вроде logo.123abc45.png.
  Пример в Blade:

  <img src="{{ Vite::asset('resources/images/logo.png') }}" alt="Logo">
  

  В итоге в продакшене будет примерно так:

  https://ваш-домен/build/logo.123abc45.png
  

Где хранить статические файлы

Статические дизайнерские ресурсы, которые являются частью «фронтенда» (логотипы, иконки, картинки дизайна, JS, CSS), обычно кладут в директорию resources/ (внутри resources/images, resources/js, resources/css и т. п.). Далее они обрабатываются/минифицируются/склеиваются в процессе сборки через Vite, и в продакшен-сборке получают хеши для кэширования.

Если использовать Laravel 9+ с Vite, то минимальная настройка сводится к тому, чтобы:

• установить зависимости vite и Laravel Vite плагин,
• настроить vite.config.js (например, указать resources/js/app.js и resources/css/app.css как точки входа),
• использовать в Blade-шаблонах @vite(['resources/js/app.js', 'resources/css/app.css']), чтобы подключить скомпилированные скрипты и стили.

Все картинки, которые тоже являются неотъемлемой частью дизайна, можно подключать через Vite::asset('resources/...'), либо импортировать прямо в Vue/React/JS и также использовать в шаблонах.

Где хранить динамические файлы

Динамические файлы обычно относятся к пользовательскому контенту. К примеру:

• Аватарки,
• Фотографии,
• PDF-документы,
• Архивы,
• Любые другие загруженные или генерируемые в процессе работы приложения файлы.

Хранятся они в директории storage/app/public (или в другом месте, если необходимо), а доступ к ним в публичной части достигается с помощью симлинка public/storage. По умолчанию команда:

php artisan storage:link

создаёт такую символическую ссылку, позволяя обратиться к файлам по пути https://ваш-домен/storage/....

В Blade-шаблонах для этих файлов обычно пишут:

<img src="{{ asset('storage/contacts/3.jpg') }}" alt="User photo">

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

Практические советы

1. Разнесите дизайн и контент. Все ваши “дизайнерские” ресурсы, которые идут вместе с интерфейсом, лучше держать в resources/ и собирать через Vite. Это даёт плюс в виде автоматического «versioning» — пользователь увидит обновлённую картинку или стили, даже если у него был закэширован старый файл.

2. Не пихайте в Vite то, что постоянно меняется. Фотографии пользователей и прочий динамический контент нельзя или неэффективно собирать через фронтенд-бандлер. К тому же при любом обновлении содержимого вам бы пришлось пересобирать фронтенд — а это лишняя нагрузка. Пусть динамика живёт в storage/.

3. Используйте правильный хелпер.

   • Для файлов, которые собраны Vite: Vite::asset('resources/images/logo.png').
   • Для файлов, которые лежат в storage/app/public: asset('storage/contacts/3.jpg').

4. Следите за симлинком. Если при попытке открыть ссылку https://ваш-домен/storage/... видите ошибку 404, убедитесь, что симлинк public/storage корректно создан, а права доступа настроены правильно.

5. Оптимизация и безопасность. Если вы держите большие файлы в storage (например, архивы или PDF), подумайте о том, чтобы хранить их в облаке (AWS S3, DigitalOcean Spaces и т. д.) и выдавать ссылки оттуда. Laravel удобно работает с разными дисками хранения через Filesystem. Это разгружает ваш сервер и упрощает масштабирование.

Вывод

Разделение статических (дизайнерских) и динамических (пользовательских) файлов — залог удобства в поддержке Laravel-проекта. Статические файлы, которые не меняются на лету, целесообразно собирать через Vite и использовать Vite::asset(). Динамические файлы, которые меняются и загружаются пользователями, следует отправлять в storage и подтягивать через asset().

Таким образом, вы обеспечите удобство работы в команде, гибкое кэширование, быструю загрузку фронтенда и простое хранение пользовательского контента без «ломания» бандла при каждом изменении.