Будущий релиз Symfony 4.0 и проект с использованием Symfony Flex / forpes.ru

Главная
Будущий релиз Symfony 4.0 и проект с использованием Symfony Flex

Будущий релиз Symfony 4.0 и проект с использованием Symfony Flex +4

23.11.2017 13:11

cawakharkov 15 3100 Источник

30 Ноября 2017 года состоится релиз Symfony 4.0

Четвертая версия имеет ряд глобальных изменений, основным из которых можно назвать переход на Symfony Flex.

Что же такое Symfony Flex?

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

Существует 2 репозитория с рецептами:

Настройка рецепта происходит через manifest.json который содержит набор конфигураторов и опций.

Опции

aliases
Используется для указания альтернативного имени рецепта. Например без использования этой опции рецепт устанавилвается так:

composer req acme-inc/acme-log-monolog-handler

Добавив в manifest.json

{
    "aliases": ["acme-log", "acmelog"]
}

можно будет использовать

composer req acme-log

Конфигураторы

Набор задач которые будут выполнены при установке рецепта.
bundles

Подключение одного или нескольких бандлов с возможностью указания окружения.

{
    "bundles": {
        "Symfony\\Bundle\\DebugBundle\\DebugBundle": ["dev", "test"],
        "Symfony\\Bundle\\MonologBundle\\MonologBundle": ["all"]
    }
}

container
Добавление параметров контейнера в services.yaml, например локаль:

{
    "container": {
        "locale": "en"
    }
}

copy-from-package
Копирует папки или файлы из пакета в проект:

{
    "copy-from-package": {
        "bin/check.php": "%BIN_DIR%/check.php"
    }
}

Доступные константы:

%BIN_DIR%, %CONF_DIR%, %CONFIG_DIR%, %SRC_DIR% %VAR_DIR%, %PUBLIC_DIR%

copy-from-recipe
Копирование файлов и директорий из самого рецепта:

"copy-from-recipe": {
    "config/": "%CONFIG_DIR%/",
    "src/": "%SRC_DIR%/"
}

env
Добавление параметров в .env и .env.dist:

{
    "env": {
        "APP_ENV": "dev",
        "APP_DEBUG": "1"
    }
}

Можно сгенерировать рандомную 16 битную строку используя %generate(secret)%

gitignore
Добавляет паттерны в .gitignore:

{
    "gitignore": [
        ".env",
        "/public/bundles/",
        "/var/",
        "/vendor/"
    ]
}

post-install-output
Определяет контент, который будет показан после установки рецепта, должен быть определён в файле post-install.txt, каждая строка закрывается PHP_EOL.
Поддерживаются консольные цвета\стили.

Полный пример manifest.json для symfony/framework-bundle:

{
    "bundles": {
        "Symfony\\Bundle\\FrameworkBundle\\FrameworkBundle": ["all"]
    },
    "copy-from-recipe": {
        "config/": "%CONFIG_DIR%/",
        "public/": "%PUBLIC_DIR%/",
        "src/": "%SRC_DIR%/"
    },
    "composer-scripts": {
        "make cache-warmup": "script",
        "assets:install --symlink --relative %PUBLIC_DIR%": "symfony-cmd"
    },
    "env": {
        "APP_ENV": "dev",
        "APP_DEBUG": "1",
        "APP_SECRET": "%generate(secret)%"
    },
    "gitignore": [
        ".env",
        "/public/bundles/"
        "/var/",
        "/vendor/"
    ]
}

Собираем первый проект на Symfony Flex

Будем использовать последнюю доступную на момент написания статьи версию — «v4.0.0-RC1»

Для начала нам понадобится composer.

Давайте создадим проект:


composer create-project symfony/skeleton flex-test-project "v4.0.0-RC1"

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

composer config extra.symfony.allow-contrib true

или самостоятельно добавить

"extra": {
        "symfony": {
          "allow-contrib": "true"
        }

в composer.json

Для запуска можно использовать встроеный в PHP веб-сервер или поставить web-server-bundle через его рецепт:


composer req web-server
bin/console server:start

Так же, нам потребуется профайлер и генератор, который теперь называется maker-bundle.
Для профайлера необходим twig.


composer req twig
composer req web-profiler-bundle

А для генератора аннотации так же возможно необходимо будет понизить требования к minimum-stability в *composer.json*.

 "minimum-stability": "dev"


composer req maker
composer req annotations
bin/console make:controller

Готово.

Для поиска по рецептам можно использовать https://symfony.sh/.
Основные изменения в грядущей версии.
Репозиторий на github
Апгрейд с 3.* до 4.*

Комментарии (15)

timelle
23.11.2017 16:19
#10535122
Интересно! Сравнение не совсем корректное, однако, рецепты очень похожи на сниппеты в MODX.

sam002
23.11.2017 18:18
#10535376
+1
Может я отстаю от тренда или чего не понял, но очень не понравился flex в реальном проекте. Слишком много магии и большая сложность если с нуля разбираться.
У flex, имхо, целевая аудитория должна быть — DevOps-ы, но зачем тогда такой узкоспециализированный инструмент?
1. cawakharkov Автор
  23.11.2017 18:35
  #10535406
  Ну пока да, выглядит как сложность для разработчиков, но бандлы и пакеты подключать действительно проще, хоть и накладывает на их разработчиков некоторые требования.
1. shoomyst
  24.11.2017 00:26
  #10535786
  В чем там магия и сложность?
  Почему для devops? Это удобно для быстрых шаблонных проектов.
  1. sam002
    24.11.2017 14:06
    #10536364
    1) Магия для конечного пользователя — куча системных зависимостей получается.
    2) Вот для чего, например, надо сводить в один инструмент git и env? Это же чисто упрощение развертывания, а не разработки. Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.
    
    pbatanov
    25.11.2017 12:41
    #10537450
    Где свели в один инструмент git и env? если вы про dotenv, то по факту это инструмент, позволяющий мокать энвы через файл для локальных окружений, где их тяжело поддерживать одинаковыми путем системных инструментов. Он даже «по канону» включается только тогда, когда не определена перенная APP_ENV в окружении
    
    Также этот инструмент позволяет использовать .env файлы, которые использует тот же docker compose для того, чтобы не пересобирать приложение во время разработки
    
    Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах
    
    Fesor
    26.11.2017 16:10
    #10538554
    +1
    Магия для конечного пользователя — куча системных зависимостей получается.
    Предположим что мы начали проект с использованием flex и поставили при помощи него 10 пакетов. Наш проект зависит от этих 10-ти пакетов. Можем ли мы добавить еще/удалить их без использования flex? можем. Стало быть зависимости нашего проекта от flex нету. Можем ли мы менять зависимости без composer? можем но сложно, так как наш проект зависит от системы автозагрузки классов composer-а. Однако эта связь осуществляется через абстракцию — slp_autoload. То есть мы можем спокойно заменить ее на свою, но вряд-ли вы будете так делать.
    
    Резюмирую вопрос. Какие кучи системных зависимостей вы видите?
    
    надо сводить в один инструмент git и env?
    а откуда взялся git в этой связке? Вы можете использовать symfony flex и без git. Например если все зависимости спокойно можно стянуть по http.
    
    Это же чисто упрощение развертывания, а не разработки.
    а вы не разворачиваете то что разработали? Даже локально?
    
    Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.
    Давайте прикинем что нам нужно копипастить/генерировать:
    
    копипастить конфиги модулей, даже если нам требуется дефолтные настройки
    
    генерировать… да ничего нам не нужно генерировать.
    
    То есть flex — это чисто для копипасты конфигов при установке пакетов. IDE нам тут не поможет. Если вы предлагаете копипастить конфиги из шаблонного проекта — это значит что нам надо сделать такой проект и поставить туда все эти пакеты. Причем даже те которые вам не нужны по дефолту.
    
    К чему это нас приводит:
    
    жирный стартовый проект переполненный зависимостями которые вам не нужны
    
    подсознательное стремление разработчиков обойтись тем что есть что бы "не ставить нового ибо надо будет копипастить конфиги уже из ридми".
    
    усложнение флоу разработки.
    
    Что же предлагает нам flex — лишь возможность разработчикам пакетов описать "настройки по умолчанию" которые в явном виде будут автоматически прописываться в ваш проект. Далее разработчику остается лишь подправить настройки под себя. Отпадает необходимость держать переполненный зависимостями шаблонный проект и использовать ровно то что нужно.
1. VolCh
  24.11.2017 06:07
  #10535868
  Причём тут девопсы вообще? Ну и никто не запрещает вам не использовать flex, а устанавливать и, главное, конфигурировать пакеты по старинке — для девопсов разницы нет, кроме того, что минус одна зависимость, причём с большей вероятностью могущей вызвать проблемы при обновлении, поскольку это не либа или бандл, а композер плагин.

porn
24.11.2017 00:22
#10535782
С весны слежу за skeleton. Поддерживаю предыдущего оратора и очень интересен взгляд Fesor на это.
1. Fesor
  24.11.2017 00:40
  #10535796
  Поддерживаю предыдущего оратора
  в чем именно? в том что "целевая аудитория — дэвопсы"?
  
  devops это идея о том что dev-ы и ops-ы должны меньше сориться и больше общаться. Это и менеджмент конфигураций нормальный и все такое. нынче дефакто стандарт — переменные окружения и секреты, контейнеры и все такое. Это затрагивает обе стороны. Можете подробнее познакомиться с идеями что есть современный бэкэнд: https://12factor.net/
  
  по поводу магии — это просто плагин для composer. Не вижу никакой черной магии которую стоит бояться.
  
  мне нравится идея что дефолтные настройки бандла будут сами добавляться и не нужно будет тратить пару минут на редактирование конфигов. Это позволит больше дробить проекты на небольшие пакеты и проще будет их менеджить.
  
  мне в symfony flex нравится все кроме makefile-ов разве что но вроде как от них отказались
  1. VolCh
    24.11.2017 06:08
    #10535870
    Да, отказались после публичного голосования, добавив symfony/console в основные зависимости скелета.
  1. gaaarfild
    24.11.2017 12:24
    #10536178
    А чем именно мейкфайлы не нравятся?
    
    VolCh
    24.11.2017 16:15
    #10536546
    
    Лишняя системная зависимость, не везде может быть из коробки, а где-нить под Windows установить непросто, наверное
    
    Не самый очевидный синтаксис и семантика для тех, кто видит его раз в полгода
    
    Если говорить именно о symfony, то в большинстве случаев просто ланчер для bin/console, иногда с фолбэками, иногда просто ошибку выводящий

denis-vc
27.11.2017 11:37
#10539430
+1
Для начала нам понадобится консольтная утилита symfony lnstaller:

Как раз она нам и не понадобится. И это видно дальше по тексту. Symfony Flex — это замена инсталлятору. Реализованная в виде плагина к composer. С помощью этого плагина можно поставить и предыдущие версии Symfony (3.3 точно ставится).

Суть улучшения в более кросс-технологичных соглашениях (public vs web, config vs app/config, .env vs app/config/parameters.yml, *.yaml vs *.yml, etc). И в большей автоматизации на основе этих соглашений. Отдельные элементы автоматизации методично добавлялись и вылизывались в течение всех релизов третьей ветки (а некоторые появились ещё в 2.x).

Магия там под строгим контролем: любая неоднозначность при компиляции заканчивается бросанием исключения. И требует ручного конфигурирования.

Но, если совсем грубо, правильно описанные и разложенные абстракции, позволяют автоматически нагенерить очень много конкретики. И получить гораздо больше удовольствия от замечательного шаблона DI.

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

cawakharkov Автор
27.11.2017 11:38
#10539436
Про инсталлер — забыл удалить.