Symfony 4.0 выйдет в релиз в конце ноября 2017 года. Следующие несколько недель будут опубликовываться статьи о новых идеях и основных изменениях в Symfony 4.
Symfony 3.0 был скучным и являлся более лаконичной версией Symfony 2.8:
Symfony 3.0 = Symfony 2.8 — Deprecated Features.
Но что же будет представлять из себя Symfony 4.0 в отличии предыдущих версий:
Symfony 4.0 = Symfony 3.4 — Deprecated Features + Новые концепции разработки приложений.
Или вот еще один вариант развития событий:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x — Deprecated Features + Новые концепции разработки приложений.
Но самое главное — Symfony 4.0 будет требовать PHP 7. А теперь о новых концепциях разработки.
У Symfony достаточно громоздкий процесс установки внешних бандлов:
На данный момент установка нового бандла одним композером зачастую не обходится.
Как это обычно происходит:
- Загрузка необходимых зависимостей через composer require symfony/bundle
- Регистрация бандла в app/AppKernel.php
- Регистрация маршрутов, которые предоставляет наш новый бандл, если таковые имеются
- Регистрация необходимых настроек для бандла в app/config/config.yml
Первый шаг автоматизировать не представляется возможным, хотя чувствуется, что сам процесс можно будет сделать более удобным для конечного разработчика.
Теперь посмотрим на 3 и 4 этапы. Процесс регистрации конфигов для новых бандлов вполне реально автоматизировать, но скорее всего это будет выглядеть как обычная вставка стандартного набора настроек для бандла, при котором он может стабильно функционировать, как это сделано в Symfony Standart Edition для некоторых предустановленных пакетов.
Ведь если вы взгляните на README любого популярного бандла: все они начинаются с одних и тех же танцев с бубном — как сконфигурировать то, что вы только что установили.
Удаление бандла в Symfony — это еще большая боль
Если вам необходимо удалить сторонний симфони бандл, который вы недавно установили, то вам недостаточно будет сделать composer remove symfony/bundle. Помните, что нам нужно проделать при установке нового бандла? Ну так вот, теперь нам необходимо так же вручную удалять всё то, что мы тогда понаписали.
В Symfony Standart Edition тоже не все так хорошо
Команда Symfony уже предпринимала попытку предоставить разработчикам определенную отправную точку для начала разработки определенных типов веб-приложений.
Самый популярный тип веб-приложений — это обычные традиционные приложения, которые мы привыкли видеть. Они используют базу данных, систему шаблонов, возможно они даже отправляют письма на почту своим пользователям.
Но что если вы хотите сделать API или Web Service? А может вы хотите собственный Micro Framework Style?
Symfony Standart Edition конечно же предоставляет выбор разработчику, но для быстрого старта и полной свободы все-таки нам либо чего-то не будет хватать, либо наоборот — слишком много лишних зависимостей. Дистрибутивы для Symfony не масштабируются: нет возможности гибко добавить необходимые зависимости в проект, которые не были заранее установлены, но нужны для полноценного функционирования, как и нет возможности быстро избавиться от ненужных.
Другой вопрос с дистрибутивами это то, что возможно вы не хотите хранить в своем проекты файлы типа: LICENSE и README. Многие проекты не имеют MIT лицензии вообще, как и зачастую может не быть необходимости в README.
Несколько лет назад Symfony Standart Edition предоставили небольшое демо для быстрого старта, но мы убрали его после того как люди встретили некоторые затруднения при удалении ненужных вещей в проекте. Это было и хорошим и плохим решением. Это сделало Standart Edition хуже, т. к. разработчики больше не имели примеров, но с другой стороны им больше не приходилось подчищать все вручную.
Еще не убедил? Посмотрите на README REST дистрибутива:
Понятие дистрибутива не очень подходит Symfony
И, наверное, поэтому дистрибутивы Symfony никогда не взлетали. Помимо Standart Edition, ни один из них не пользуется популярностью, поэтому мы опубликовывали только 3 из них:
Hello World Edition, Symfony CMF Standard Edition, Symfony REST Edition.
Сами дистрибутивы недостаточно гибки, они не могут развиваться. Дистрибутивы являются неверной абстракцией, нам не нужен полностью загруженный проект, нам необходима возможность развивать и дополнять наше приложение с течением времени.
Идеальный вариант
Как разработчик, я хочу начать с чего-то малого, без множества зависимостей, тем временем я хочу иметь возможность совершенствовать свое приложение так, как считаю нужным. От Micro-Framework style до огромного монолита и фреймворк не должен здесь мешать.
Начинать новый проект с Symfony или дорабатывать уже существующий слишком сложно для начинающих и слишком громоздко для продвинутых разработчиков. Мы можем сделать лучше.
Композицию наследованию
Большинство дистрибутивов представляют из себя форки Symfony Standart Edition с дополнительными бандлами. А что насчет композиции? Что если я хочу использовать дистрибутив API с Admin? Нужны ли мне здесь новые дистрибутивы? Возможно нет.
Symfony Flex — новый способ, который позволяет создать и поддерживать ваше приложение с легкостью. Это то, что упрощает создание приложений любых типов, от самых простых проектов в Micro-Framework Style, до проектов с огромным количеством зависимостей. Он автоматизирует добавление и удаление пакетов, заботится о том, чтобы задать без вашего участия разумную конфигурацию для нового пакета и многое другое.
Symfony Flex будет использоваться по умолчанию для управления приложениями на Symfony 4, тем не менее он будет доступен в качестве необязательного компонента для управления приложениями на Symfony 3.3 и 3.4. Альфа версия Symfony Flex будет выпущена перед выходом Symfony 4.
Оставайтесь с нами, следующий пост расскажет вам больше о Symfony Flex. А пока оценим новый скелет приложения с Symfony Flex. Не совсем то, что вы ожидали, верно?
Автор: Андреев Данил
