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

  • Tutorial

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



image

Четвертая версия имеет ряд глобальных изменений, основным из которых можно назвать переход на 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.*
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 15

    0
    Интересно! Сравнение не совсем корректное, однако, рецепты очень похожи на сниппеты в MODX.
      +2
      Может я отстаю от тренда или чего не понял, но очень не понравился flex в реальном проекте. Слишком много магии и большая сложность если с нуля разбираться.
      У flex, имхо, целевая аудитория должна быть — DevOps-ы, но зачем тогда такой узкоспециализированный инструмент?
        0
        Ну пока да, выглядит как сложность для разработчиков, но бандлы и пакеты подключать действительно проще, хоть и накладывает на их разработчиков некоторые требования.
          –1
          В чем там магия и сложность?
          Почему для devops? Это удобно для быстрых шаблонных проектов.
            0
            1) Магия для конечного пользователя — куча системных зависимостей получается.
            2) Вот для чего, например, надо сводить в один инструмент git и env? Это же чисто упрощение развертывания, а не разработки. Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.
              +2
              Где свели в один инструмент git и env? если вы про dotenv, то по факту это инструмент, позволяющий мокать энвы через файл для локальных окружений, где их тяжело поддерживать одинаковыми путем системных инструментов. Он даже «по канону» включается только тогда, когда не определена перенная APP_ENV в окружении

              Также этот инструмент позволяет использовать .env файлы, которые использует тот же docker compose для того, чтобы не пересобирать приложение во время разработки

              Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах
                +3
                Магия для конечного пользователя — куча системных зависимостей получается.

                Предположим что мы начали проект с использованием flex и поставили при помощи него 10 пакетов. Наш проект зависит от этих 10-ти пакетов. Можем ли мы добавить еще/удалить их без использования flex? можем. Стало быть зависимости нашего проекта от flex нету. Можем ли мы менять зависимости без composer? можем но сложно, так как наш проект зависит от системы автозагрузки классов composer-а. Однако эта связь осуществляется через абстракцию — slp_autoload. То есть мы можем спокойно заменить ее на свою, но вряд-ли вы будете так делать.


                Резюмирую вопрос. Какие кучи системных зависимостей вы видите?


                надо сводить в один инструмент git и env?

                а откуда взялся git в этой связке? Вы можете использовать symfony flex и без git. Например если все зависимости спокойно можно стянуть по http.


                Это же чисто упрощение развертывания, а не разработки.

                а вы не разворачиваете то что разработали? Даже локально?


                Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.

                Давайте прикинем что нам нужно копипастить/генерировать:


                • копипастить конфиги модулей, даже если нам требуется дефолтные настройки
                • генерировать… да ничего нам не нужно генерировать.

                То есть flex — это чисто для копипасты конфигов при установке пакетов. IDE нам тут не поможет. Если вы предлагаете копипастить конфиги из шаблонного проекта — это значит что нам надо сделать такой проект и поставить туда все эти пакеты. Причем даже те которые вам не нужны по дефолту.


                К чему это нас приводит:


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

                Что же предлагает нам flex — лишь возможность разработчикам пакетов описать "настройки по умолчанию" которые в явном виде будут автоматически прописываться в ваш проект. Далее разработчику остается лишь подправить настройки под себя. Отпадает необходимость держать переполненный зависимостями шаблонный проект и использовать ровно то что нужно.

              +2
              Причём тут девопсы вообще? Ну и никто не запрещает вам не использовать flex, а устанавливать и, главное, конфигурировать пакеты по старинке — для девопсов разницы нет, кроме того, что минус одна зависимость, причём с большей вероятностью могущей вызвать проблемы при обновлении, поскольку это не либа или бандл, а композер плагин.
              0
              С весны слежу за skeleton. Поддерживаю предыдущего оратора и очень интересен взгляд Fesor на это.
                +1
                Поддерживаю предыдущего оратора

                в чем именно? в том что "целевая аудитория — дэвопсы"?


                1. devops это идея о том что dev-ы и ops-ы должны меньше сориться и больше общаться. Это и менеджмент конфигураций нормальный и все такое. нынче дефакто стандарт — переменные окружения и секреты, контейнеры и все такое. Это затрагивает обе стороны. Можете подробнее познакомиться с идеями что есть современный бэкэнд: https://12factor.net/
                2. по поводу магии — это просто плагин для composer. Не вижу никакой черной магии которую стоит бояться.
                3. мне нравится идея что дефолтные настройки бандла будут сами добавляться и не нужно будет тратить пару минут на редактирование конфигов. Это позволит больше дробить проекты на небольшие пакеты и проще будет их менеджить.

                мне в symfony flex нравится все кроме makefile-ов разве что но вроде как от них отказались

                  0
                  Да, отказались после публичного голосования, добавив symfony/console в основные зависимости скелета.
                    0

                    А чем именно мейкфайлы не нравятся?

                      +1
                      1. Лишняя системная зависимость, не везде может быть из коробки, а где-нить под Windows установить непросто, наверное
                      2. Не самый очевидный синтаксис и семантика для тех, кто видит его раз в полгода
                      3. Если говорить именно о symfony, то в большинстве случаев просто ланчер для bin/console, иногда с фолбэками, иногда просто ошибку выводящий
                  +3
                  Для начала нам понадобится консольтная утилита 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.

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

                    Only users with full accounts can post comments. Log in, please.