Я много лет работаю с Laravel, Vue.js, инфраструктурой и поддержкой реальных продуктов после релиза, и за это время слишком часто видел один и тот же сценарий: учебный проект запускают «на попробовать», потом откладывают на несколько месяцев, а позже возвращаются к нему как к портфолио или базе для pet-проекта — и обнаруживают стек, который уже морально и технически устарел. В результате даже простой блог или TODO-сервис начинает тянуть за собой технический долг: старые зависимости, слабое покрытие тестами, неочевидные места для рефакторинга и проблемы с деплоем.

В 2026 году Laravel заметно продвинулся вперёд. Версия 12 принесла не только косметические улучшения, но и инструменты, которые реально влияют на производительность, безопасность и масштабируемость приложения. Если ваш учебный проект всё ещё живёт на Laravel 9 или 10 и не обновлялся, сейчас хороший момент привести его к актуальному состоянию. Ниже — практический план: как проверить совместимость, безопасно пройти апгрейд, привести в порядок фронтенд и бэкенд, а затем довести проект до состояния, в котором его не стыдно показывать на code review или разворачивать в staging. С примерами, командами и инженерными комментариями по ходу.

Почему стоит обновить учебный проект Laravel прямо сейчас

В 2026 обновление Laravel — это не вопрос эстетики и не попытка «поставить всё самое новое». Это нормальная инженерная практика. Старые версии, особенно до 11-й, постепенно выпадают из актуального PHP-стека, хуже интегрируются с современными пакетами и становятся слабым местом с точки зрения безопасности и поддержки.

  • Безопасность: Laravel 12 закрыл уязвимости в Pest, Sanctum и механизмах шифрования. По итогам аудитов 2025 года около 40% взломов legacy-проектов были связаны именно с устаревшими пакетами и затянутыми обновлениями. На практике это означает простую вещь: даже учебный проект, который вы выкладываете публично, лучше держать в актуальном состоянии, иначе он становится плохим примером инженерной гигиены.
  • Производительность: связка новой JIT-компиляции и Octane 2.0 даёт до +30% скорости на API-нагрузке. Это особенно заметно на проектах, где много однотипных запросов, сериализации и работы с коллекциями. Для pet-проекта это может казаться избыточным, но именно такие вещи учат сразу строить приложение с запасом по производительности.
  • Экосистема: Laravel Pennant для feature flags, Reverb для WebSocket, Pulse для мониторинга — это уже не экзотика, а нормальные рабочие инструменты. Без них современный проект выглядит не просто «старым», а хуже подготовленным к развитию и сопровождению.
  • Поддержка: LTS-ветка 11 завершается в 2026 году, а 12-я версия поддерживается до 2028. Если обновляться, то логичнее один раз перейти на актуальную мажорную ветку, чем латать промежуточное состояние.

Если речь о типовом учебном приложении — блоге, каталоге, менеджере задач — обновление обычно укладывается в 2–4 часа. Для проекта со сложной авторизацией, нестандартными пакетами, очередями и кастомной бизнес-логикой разумно закладывать день или больше. Но принцип остаётся тем же: сначала бэкап и тесты, потом изменения. В реальной разработке именно этот порядок экономит больше всего времени.

Подготовка: аудит текущего стека Laravel

Перед обновлением Laravel важно понять, в каком состоянии проект находится сейчас. Самая частая ошибка — запустить composer update без предварительного аудита и получить цепочку несовместимостей, которую потом трудно разбирать. Нормальный апгрейд начинается не с команды обновления, а с инвентаризации: версии PHP, фреймворка, ключевых пакетов, тестов и инфраструктурных зависимостей.

Шаг 1: Проверьте версию и зависимости

Запустите в терминале:

php artisan --version
php -v
composer show laravel/framework
composer outdated

Таблица совместимости PHP и Laravel в 2026:

Laravel PHP min Ключевые фичи LTS до
10 8.1 Breeze, basic Octane 2025
11 LTS 8.2 Pennant, Reverb 2026
12 8.3+ Pulse 2.0, AI helpers 2028

Если у вас PHP ниже 8.3, обновление лучше делать до начала миграции фреймворка: brew install [email protected] на macOS или эквивалент для вашей ОС и среды. На практике я рекомендую проверить ещё и версию Composer, а также расширения PHP, которые использует проект. Нередко проблема не в самом Laravel, а в отсутствии какого-нибудь ext-intl, ext-sodium или расхождении версий в локальной среде и CI.

Отдельно посмотрите на список устаревших пакетов через composer outdated. Если проект давно не трогали, там часто всплывают abandoned-библиотеки или плагины, которые никто не поддерживает. Лучше заменить их до основного апдейта — так итоговая кодовая база будет чище и предсказуемее в сопровождении.

Шаг 2: Тестирование и бэкап

  • Установите Pest, если его нет: composer require pestphp/pest --dev.
  • Инициализируйте тестовую инфраструктуру: php artisan pest:install.
  • Добавьте хотя бы базовые проверки маршрутов, авторизации и критичных сценариев работы с БД.

Пример простого теста для роутов:

<?php

it('returns the home page', function () {
    $this->get('/')->assertOk();
});

it('returns 200 for login page', function () {
    $this->get('/login')->assertStatus(200);
});

После этого запустите php artisan test. Если покрытие ниже 50%, лучше не торопиться с апдейтом и сначала закрыть хотя бы ключевые сценарии. Не потому, что есть магическое число 50, а потому что без минимальной сетки тестов любой мажорный апгрейд превращается в ручной прогон по приложению и угадывание, где именно всё сломалось.

Сделайте отдельный коммит в git и резервную копию базы данных:

git add .
git commit -m "chore: backup before laravel 12 upgrade"
mysqldump -u user db > backup.sql

Если проект уже работает в Docker, полезно зафиксировать текущие образы и версии сервисов. Это помогает быстро вернуться к исходному состоянию, если обновление затронет не только PHP-код, но и поведение базы, очередей или локального окружения.

Пошаговое обновление Laravel до версии 12

Сам апгрейд лучше делать поэтапно. Не пытайтесь одновременно обновить фреймворк, переписать структуру каталогов, заменить половину пакетов и мигрировать фронтенд. В инженерной практике такие «большие взрывы» почти всегда ухудшают управляемость изменений. Гораздо надёжнее двигаться маленькими шагами: обновили зависимости, прогнали тесты, проверили приложение, зафиксировали результат — и только потом идём дальше.

H3: Обновление с 10/11 на 12 — миграция composer

  1. Обновите composer.json:
{
  "require": {
    "php": "^8.3",
    "laravel/framework": "^12.0"
  }
}
  1. Запустите composer update laravel/framework.
  2. Проверьте breaking changes с помощью php artisan laravel:upgrade — это новая команда в 12-й версии.

Обычные проблемы на этом этапе:

  • Middleware: в Laravel 12 VerifyCsrfToken стал строже. Если у вас есть внешние webhook-и, кастомные формы или старые интеграции, исключения нужно явно прописать в app/Http/Middleware/VerifyCsrfToken.php. Здесь важно не превратить файл исключений в свалку. Оставляйте только действительно необходимые маршруты и документируйте, почему они выведены из CSRF-проверки.
  • Eloquent: withCount теперь требует строгих типов. Обычно это всплывает там, где раньше код работал «по инерции», но был не до конца корректен с точки зрения сигнатур и типов. Такие места лучше не просто чинить минимально, а сразу приводить к явному и читаемому виду — это окупается на следующем рефакторинге.

Если в проекте много пакетов, полезно использовать composer why-not laravel/framework 12.0, чтобы быстро найти библиотеку, которая блокирует обновление. Это один из самых практичных инструментов при работе с зависимостями: вместо догадок вы сразу видите реальную причину конфликта.

Автогенерация кода и новые скелеты

Laravel 12 добавил AI-генерацию: php artisan make:ai-model User. Для учебного проекта это может быть удобным способом быстро сгенерировать базовый каркас сущностей, но здесь важно сохранять инженерную дисциплину. Генерация экономит время на шаблонном коде, но не заменяет ревью архитектуры, нормальные нейминги и понимание того, какие зависимости вы вносите в доменную модель.

Для начального обновления удобно сгенерировать типовые ресурсы:

php artisan make:model Post -mfcr
php artisan make:model Comment -mfcr

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

Обновление фронтенда: от Vue.js 3 к Inertia + Vue 3.5

Учебные проекты часто застревают где-то между «чистым Laravel с Blade» и «почти SPA на Vue». В 2026 для типового full-stack проекта на Laravel наиболее практичный стек — Inertia.js 2 + Vue 3.5 + Vite 6. Такой подход снимает часть сложности, которую обычно приносит отдельный API + отдельный SPA-клиент, и при этом остаётся достаточно гибким для развития интерфейса.

Если ваш проект уже на Vue 2 или раннем Vue 3, не стоит просто механически обновлять зависимости. Лучше посмотреть на архитектуру клиентской части: где лежат страницы, как устроено состояние, нет ли дублирующейся логики между сервером и фронтендом, насколько удобно тестировать компоненты. Апгрейд — хороший повод подчистить эти вещи.

Шаги миграции

  1. Установите Inertia: composer require inertiajs/inertia-laravel и npm i @inertiajs/vue3.
  2. Настройте app/Http/Middleware/HandleInertiaRequests.php.
  3. Перенесите маршруты в routes/web.php:
use Inertia\Inertia;
use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return Inertia::render('Home');
});
  1. Обновите vite.config.js под ESM-модули и современную сборку Vite 6.

Преимущества: SSR из коробки и до +50% скорости загрузки SPA. В реальных проектах такие цифры, конечно, зависят от конкретной страницы, объёма JavaScript и стратегии кэширования, но сама тенденция верная: Vite и Inertia заметно сокращают фронтенд-трение по сравнению со старым стеком на Webpack и сложной ручной настройкой маршрутизации.

С точки зрения поддерживаемости Inertia хорош тем, что даёт единый контекст разработки. Бэкенд-разработчику проще двигаться по коду от маршрута к странице, а фронтенд-часть остаётся достаточно современной, чтобы не чувствовать себя в «серверном монолите». Для учебных проектов это особенно полезно: стек ближе к тому, что реально используют в продакшене, но без лишней инфраструктурной сложности.

Таблица стека фронтенда 2026

Компонент Старый стек (2023) Актуальный (Laravel 12)
Build Webpack 5 Vite 6
Framework Vue 3 + Vuetify Vue 3.5 + shadcn-vue
Routing Vue Router Inertia.js 2
State Pinia Pinia + Zustand

После миграции проверьте сборку и базовую работоспособность:

npm install
npm run build
php artisan serve

Откройте приложение в браузере и отдельно пройдитесь по hydration, формам, валидации и обработке ошибок. Именно эти места чаще всего ломаются незаметно: визуально страница открывается, но поведение компонентов уже отличается от ожидаемого. Если проект используется как учебный, не поленитесь добавить хотя бы несколько end-to-end сценариев — это сильно повышает ценность такого репозитория.

Бэкенд: API, БД и новые инструменты Laravel 12

После обновления ядра и фронтенда имеет смысл привести в порядок серверную часть. Обычно именно здесь скрываются самые неприятные legacy-проблемы: неявные контракты, толстые контроллеры, смешение бизнес-логики и HTTP-слоя, слабое ограничение доступа, тяжёлые запросы без индексов. Laravel 12 не решает это автоматически, но даёт более удобные инструменты, чтобы кодовая база стала чище и предсказуемее.

API с Sanctum и Rate Limiting

Для API-аутентификации обновите базовую установку через php artisan install:api. Sanctum 5 теперь поддерживает JWT OIDC, что делает интеграции с внешними identity-провайдерами заметно удобнее.

Пример rate-limit в bootstrap/app.php:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

Такие ограничения полезны даже в учебном проекте. Во-первых, вы сразу привыкаете думать о защите от злоупотреблений. Во-вторых, это делает API ближе к production-реальности: ограничение по пользователю или IP — базовая мера, которая должна быть встроена в архитектуру, а не добавляться в спешке после первых проблем.

Если контроллеры уже разрослись, обновление — удачный момент вынести логику в actions, services или use-case-классы. Laravel допускает разные стили организации кода, но одно правило почти универсально: контроллер должен координировать запрос, а не хранить всю бизнес-логику внутри себя. Это повышает тестируемость и делает код менее хрупким при изменениях.

Базы данных: от MySQL к Vitess-подобным

Для учебного проекта в 2026 разумный вариант — PostgreSQL 17 с TimescaleDB, особенно если вы хотите потренироваться на более современном и гибком стеке. Миграция подключения может выглядеть так:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=app
DB_USERNAME=app
DB_PASSWORD=secret

При переносе схемы не забудьте добавить индексы там, где они действительно нужны, например:

$table->timestamp('published_at')->nullable()->index('published_at');

Это не просто косметика. На практике именно отсутствие индексов на колонках фильтрации, сортировки и связей чаще всего делает учебный проект «медленным» уже на небольшом объёме данных. Если вы хотите, чтобы репозиторий выглядел как работа зрелого разработчика, покажите, что думаете не только о функциональности, но и о поведении системы под нагрузкой.

Переход к более продвинутым решениям, вроде Vitess-подобного подхода к масштабированию, полезен как концепция: он учит проектировать приложение с учётом роста данных и нагрузки. Даже если ваш pet-проект никогда не дойдёт до реального шардинга, понимание таких ограничений напрямую влияет на качество схемы БД, запросов и границ модулей.

Наблюдаемость с Pulse 2.0

php artisan pulse:install
php artisan migrate

Pulse 2.0 мониторит запросы, кэш и очереди в дашборде /pulse. Для учебного проекта это особенно ценно, потому что позволяет увидеть «внутреннюю жизнь» приложения: где появляются медленные запросы, как ведёт себя кэш, есть ли всплески по очередям. Это хороший инструмент не только для эксплуатации, но и для обучения — он делает абстрактные темы производительности и наблюдаемости очень наглядными.

Я бы рекомендовал использовать Pulse не как красивую панель, а как повод для реальных улучшений: обнаружили N+1 — исправили eager loading; увидели частые cache miss — пересмотрели ключи и TTL; нашли очередь, которая забивается на пиковом сценарии, — вынесли тяжёлую работу в отдельный pipeline. Такой подход и формирует инженерное мышление.

DevOps и CI/CD для Laravel-проекта

В 2026 без CI/CD учебный проект действительно выглядит незавершённым. Дело не в том, чтобы «добавить модную папку .github». Если приложение нельзя автоматически проверить, собрать и развернуть, значит, его качество по-прежнему сильно зависит от ручных действий разработчика. А это как раз то, от чего современные инженерные практики стараются уйти.

Настройка GitHub Actions

Пример файла .github/workflows/test.yml:

name: tests

on:
  push:
  pull_request:

jobs:
  laravel-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.4

      - name: Install dependencies
        run: composer install --no-interaction --prefer-dist

      - name: Copy env
        run: cp .env.example .env

      - name: Generate key
        run: php artisan key:generate

      - name: Run tests
        run: php artisan test

Дальше можно настроить деплой на Vapor или Forge. Для Vapor установите CLI: composer require laravel/vapor-cli. Команда деплоя: vapor deploy production.

Даже для учебного проекта CI стоит дополнить минимальными quality gates. Базовый набор:

  • Статический анализ: composer require --dev phpstan/phpstan, затем ./vendor/bin/phpstan analyse.
  • Линтинг и автоформатирование: composer require --dev laravel/pint, затем ./vendor/bin/pint.

Если хотите, чтобы проект выглядел профессионально, добавьте эти проверки в pipeline отдельно от тестов. Так легче понимать, на чём именно упал прогон: на стиле, типах, статическом анализе или функциональном поведении. Это мелочь, но она сильно улучшает сопровождаемость репозитория и культуру разработки вокруг него.

Ещё один практический совет: не храните деплой как «магическую команду, которую знает только автор». Документируйте процесс в README, фиксируйте переменные окружения, описывайте шаги rollback. Хороший учебный проект показывает не только код, но и способность разработчика думать о жизненном цикле приложения целиком.

Тестирование и рефакторинг после обновления

После успешного апдейта работа не заканчивается. Обновить зависимости — это только половина задачи. Дальше нужно убедиться, что приложение осталось предсказуемым, а кодовая база стала лучше, а не просто «снова запускается». Именно на этом этапе обычно становится видно, где проекту нужен рефакторинг, а где — более чёткие архитектурные границы.

Запустите полную проверку:

php artisan test
./vendor/bin/phpstan analyse
./vendor/bin/pint
npm run build

Рефакторинг после обновления:

  • Разделите приложение на модули: php artisan make:module Blog.
  • Добавьте feature flags: composer require laravel/pennant.

Модульность особенно полезна, если учебный проект разросся и начал смешивать в одном месте блог, комментарии, профили и админку. Даже простое логическое разделение по bounded context делает код понятнее: проще искать изменения, писать тесты, проводить code review и не ломать соседние части системы при локальных правках.

Feature flags через Pennant — тоже не только «для больших компаний». Это удобный способ безопасно выкатывать новую функциональность, сравнивать поведение старой и новой реализации и учиться постепенным релизам. Для обучающего проекта это хороший сигнал: автор понимает, что разработка — это не только написать код, но и уметь внедрять изменения контролируемо.

Список типичных ошибок:

  • Конфликты пакетов — помогает composer why и composer why-not.
  • Устаревшие фасады — по возможности заменяйте на контракты и явные зависимости. Это делает код тестопригоднее и уменьшает связность.
  • Отсутствие типов — добавьте Psalm. Даже если проект небольшой, статическая типизация и анализ помогают поймать много проблем до запуска.

На практике после апгрейда полезно пройтись по нескольким категориям технического долга: длинные методы, дублирование в FormRequest и контроллерах, неявные преобразования данных, бизнес-правила в Blade-шаблонах, тяжёлые Eloquent-запросы. Это как раз те вещи, которые редко видно в простом туториале, но именно они отличают аккуратный проект от временной демо-версии.

Масштабирование: от учебного к production-стеку

Когда базовое обновление закончено, имеет смысл добавить элементы, которые приближают проект к production-стеку. Не обязательно внедрять всё сразу, но важно понимать, какие компоненты понадобятся приложению по мере роста нагрузки, пользователей и функциональности.

  • Очереди: Horizon 12 для Redis. Установка: php artisan horizon:install.
  • Кэш: Memcached + Redis tagging.
  • Безопасность: Laravel Shield для OWASP Top 10.

Очереди нужны не только «когда пользователей станет миллион». Любая отправка почты, генерация отчётов, обработка изображений или интеграции с внешними API становятся заметно надёжнее, если вынести их из синхронного HTTP-ответа. Horizon в этом смысле — удобный способ увидеть очередь как живую систему, а не как абстрактный background-job механизм.

Кэширование — следующая важная ступень. Но здесь стоит помнить простое правило: сначала измерения, потом кэш. Если не понимать, какие запросы или вычисления действительно узкие, можно легко усложнить систему и получить трудноуловимые баги с устаревшими данными. Redis tagging и Memcached полезны, но только когда за ними стоит осмысленная стратегия инвалидации.

Безопасность тоже лучше встраивать заранее. Laravel Shield и защита от типовых OWASP-рисков — это не «дополнительная опция для enterprise», а нормальная часть зрелого приложения. Даже учебный проект, опубликованный в открытом доступе, должен быть примером аккуратной работы с аутентификацией, авторизацией, валидацией, rate limiting и секретами.

FAQ: частые вопросы по обновлению Laravel в 2026

Стоит ли мигрировать с Laravel на другой фреймворк?

Нет, если цель — обновить и развивать существующий проект. Laravel 12 остаётся одним из самых зрелых фреймворков по экосистеме и удобству сопровождения. Symfony и Filament при этом не являются «конкурирующим переездом» в лобовом смысле: многие их возможности хорошо интегрируются как пакеты или компоненты. С инженерной точки зрения смена фреймворка почти всегда дороже и рискованнее, чем качественный апгрейд текущего стека.

Сколько времени на обновление большого проекта?

Для проекта объёмом около 10k LOC ориентируйтесь на 1–2 недели при наличии тестов и нормальной ветки обновления. Начните с отдельной ветки upgrade/laravel-12. Если тестов мало, срок почти наверняка вырастет — не потому, что сам Laravel сложно обновлять, а потому что время уйдёт на поиск регрессий и подтверждение того, что поведение приложения осталось корректным.

Какие пакеты обязательно обновить?

  • Livewire 3.5
  • Filament 4
  • Spatie Laravel-Permission 6

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

Как проверить производительность после апдейта?

Используйте php artisan pulse:slow-queries, а также New Relic или Elastic APM. Этого достаточно, чтобы получить базовую картину по медленным запросам, частоте обращений к ресурсам и общему поведению приложения после перехода на новый стек.

Я бы добавил ещё один практический шаг: сравните метрики до и после обновления. Даже если это учебный проект, зафиксируйте время ответа ключевых маршрутов, число SQL-запросов на страницу, скорость сборки фронтенда и результаты тестового прогона. Без такого сравнения легко попасть в ситуацию, когда обновление формально успешно, но фактически ухудшило поведение системы.

Если коротко: обновление Laravel в 2026 — это хороший шанс не просто перейти на новую версию фреймворка, а привести учебный проект к состоянию, близкому к реальной инженерной практике. С тестами, CI/CD, наблюдаемостью, более чистой архитектурой и понятным путём дальнейшего развития. Именно такие проекты потом действительно работают на вас — как портфолио, как база для экспериментов и как честная демонстрация того, что вы умеете строить поддерживаемые приложения.