Symfony symfony/assetic-bundle + PHP7

[scorpion-ds]

При использовании symfony/assetic-bundle вместе с PHP 7, работка в режиме dev, становится невыносимой, так как загрузка стилей и скриптов очень тормозит. В режиме prod при этом, все работает отлично.

Кто-то сталкивался с такой проблемой?
Может вообще стоит отказаться от этого assetic и все стили хранить "традиционно" где-то в папке "web"?

P.S.: В новых проектах я этим не заморачиваюсь, просто кидаю собранные (1 JS, 1 CSS) фронтом файлы в папке web и все, но есть два старых проекта, где так сделать не получиться.

 

[keltanas]

В новых версиях симфы от него уже отказались. Старые проекты либо рефакторить, либо терпеть. Был еще watch, но от него тоже не много профита.

 

[scorpion-ds]

Есть ли какая-то замена ему (кроме watch)?

Я попутно включил "use_controller: false" для dev, в создал dump стилей и скриптов, но они создались не с такими именами какие запрашиваются в шаблоне.

 

[AmdY]

Если проблемы даже с именами, то возможно траблы с правами на папки? в логах ничего нет?

 

[fixxxer]

Мне все эти попытки управления asset-ами со стороны php-фреймворка кажутся исключительной глупостью, которую зачем-то вслепую копируют с рельсов, где они, в свою очередь, были придуманы лет 10 назад, когда фронтенд-разработка сводилась к jquery. Это все годится разве что для примитивных автогенеренных админок, где фронтенд-разработки вообще как таковой нет. Ларавеловские elixir-ы точно так же идут в задницу.

В современном фронтенд-мире куча куда более удобных, производительных и надежных инструментов, о которых знает каждый фронтендщик. Со стороны сервера достаточно простейших хелперов.

 

[keltanas]

@AmdY, не, проблема в том, что ассетик в зависимости от окружения и метода подключения называет файлы по-разному. И вполне возможно, что он дампит файлы с одними именами, а подключать пытается с другими.
https://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

 

[scorpion-ds]

Разработка под видной идет, так что с правами все должно быть нормально, дамп формируется, но с другим именем, к примеру:
/js/base_jquery.1.11.1.min_1-1b7124c.js - в шаблоне;
/js/base-fcd891b_jquery.1.11.1.min_1-1b7124c.js - в дампе.

 

[AmdY]

@AmdY, не, проблема в том, что ассетик в зависимости от окружения и метода подключения называет файлы по-разному. И вполне возможно, что он дампит файлы с одними именами, а подключать пытается с другими.
https://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

не, ну это будет совсем скучно. если тупо напутаны env. хотя я недавно очень долго такой баг ловил из-за кривого билд скрипта, который кеш доктрины чистил не для того env. С теплотой вспоминал laravel с его явными .env файлами

 

[keltanas]

@AmdY, там, если я не ошибаюсь, имена разные могут быть даже в зависимости от того, так

{% javascripts '@AppBundle/Resources/public/js/*' output='js/compiled/main.js' %}
    <script src="{{ asset_url }}"></script>
{% endjavascripts %}

или так

{% javascripts '@AppBundle/Resources/public/js/script1.js' output='js/compiled/main.js' %}
    <script src="{{ asset_url }}"></script>
{% endjavascripts %}
{% javascripts '@AppBundle/Resources/public/js/script2.js' output='js/compiled/main.js' %}
    <script src="{{ asset_url }}"></script>
{% endjavascripts %}

подключаешь файлы.

@scorpion-ds, а как у тебя на странице идет подключени?

 

[AmdY]

Мне все эти попытки управления asset-ами со стороны php-фреймворка кажутся исключительной глупостью, которую зачем-то вслепую копируют с рельсов, где они, в свою очередь, были придуманы лет 10 назад, когда фронтенд-разработка сводилась к jquery. Это все годится разве что для примитивных автогенеренных админок, где фронтенд-разработки вообще как таковой нет. Ларавеловские elixir-ы точно так же идут в задницу.

Я думаю тут надо разделять конфигурирование и тулзы, в качестве конфигуратора php интерфейс выглядит логичным, другое дело что тулзы вроде less приходится заменять на нодовскую, так как php реализация медленная и с багами, помнится даже бутсрап не осиливала.
Вот elixir это плохо, мало того что поделка на ноде, так ещё чисто laravel инструмент, непонятный ни нодовцем, ни пользователям других фреймворков.

 

[scorpion-ds]

@scorpion-ds, а как у тебя на странице идет подключени?

{% block javascripts %}
                {% javascripts
                '@FCCoreBundle/Resources/public/js/jquery.1.11.1.min.js'
                '@FCCoreBundle/Resources/public/js/jquery-ui.1.10.4.min.js'
                '@FCCoreBundle/Resources/public/js/angular.min.js'
                '@FCCoreBundle/Resources/public/js/jquery.validate.js'
                '@FCCoreBundle/Resources/public/js/jquery.form.js'
                '@FCCoreBundle/Resources/public/js/jquery.cookie.js'
                '@FCCoreBundle/Resources/public/js/angular.min.js'
                '@FCCoreBundle/Resources/public/js/jquery.select-box.min.js'
                output='js/base.js'
                %}
                <script type="text/javascript" src="{{ asset_url }}?ver={{ fc_core.version }}"></script>
            {% endjavascripts %}

 

[keltanas]

@scorpion-ds, А если их поодному подключать что-то измениться?

 {% javascripts '@FCCoreBundle/Resources/public/js/jquery.1.11.1.min.js' %}
                <script type="text/javascript" src="{{ asset_url }}?ver={{ fc_core.version }}"></script>
            {% endjavascripts %}
{% javascripts '@FCCoreBundle/Resources/public/js/jquery-ui.1.10.4.min.js' %}
                <script type="text/javascript" src="{{ asset_url }}?ver={{ fc_core.version }}"></script>
            {% endjavascripts %}

А чего ?ver={{ fc_core.version }} не через бандл?

 

[keltanas]

Можно вообще как-то так сделать:

{% if app.debug %}
<script type="text/javascript" src="{{ asset('bundles/fccore/js/jquery.1.11.1.min.js') }}"></script>
<script type="text/javascript" src="{{ asset('bundles/fccore/js/jquery-ui.1.10.4.min.js') }}"></script>
<script type="text/javascript" src="{{ asset('bundles/fccore/js/angular.min.js') }}"></script>
{* ... *}
{% else %}
<script type="text/javascript" src="{{ asset('js/base.js') }}"></script>
{% endif %}

А js/base.js через грант или галп собрать. Да и можно ещё посмотреть, что такое бовер.

 

[keltanas]

@AmdY, меня вот раньше все тянуло подключать ассеты по тому же принципу, как в Yii1. Тогда это казалось удобным. Да и сайтам было достаточно jQuery и плагинов. Ассетик для того же, по сути, только еще предоставляет возможность централизованной конфигурации.

Но, мир же меняется. Фронтенд становится сложнее и сложнее. Сборка ассетов на PHP, даже в качестве менеджера становиться ужасно тормозной, и этот тред доказательство этому. А FE девелоперы уже не знают, что такое PHP, а все чаще обращаются к сферическому рест-апи.

Поэтому в настоящий момент тоже плюсую за отказ от управления фронтендом через PHP.

 

[A1x]

Поэтому в настоящий момент тоже плюсую за отказ от управления фронтендом через PHP.

тоже плюсую, лучше использовать во всех проектах одну проверенную нодовскую тулзу чем изучать свое для каждого фреймворка

все равно от ноды уже не отвертеться, помнится как меня задолбал в Yii2 этот глючный плагин к композеру, с помощью которого там вытягиваются зависимости из bower и npm, сейчас просто использую npm напрямую (bower-у отказать чтобы не плодить сущности), собираю все с помощью gulp и очень радуюсь что не приходится разбираться еще и с assetic-ом

 

[AmdY]

Но, мир же меняется. Фронтенд становится сложнее и сложнее. Сборка ассетов на PHP, даже в качестве менеджера становиться ужасно тормозной, и этот тред доказательство этому.[/USER]

А чему там тормозить? Если php управляет только конфигурацией, то и тормозить нечему, а процессинг пускай делают тулзы на ноде-гоу-руби-джава, пользователь сам может выбирать. Другое дело, что ассетик не мешало бы переписать и оптимизировать.
Но стандартная тулза для ассетов из коробки очень нужна, т.к. современный фреймворк это в первую очередь чужие бандлы и не хочется разгребать зоопарк из ассетов там. Если у тебя рест апи, то нафик симфони, да и вообще, стоит подумать а нужен ли в таком кейсе php.

 

[fixxxer]

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

Ну не все корпсайтики с магазинами клепают.

Если у тебя рест апи, то нафик симфони, да и вообще, стоит подумать а нужен ли в таком кейсе php.

Щито

 

[scorpion-ds]

@scorpion-ds, А если их поодному подключать что-то измениться?

Тоже не выходит.
Там вообще мутно как-то, CSS и JS в дамп добавляются в дублях с разными именами, но при этот отличных от тех, что запрашиваются в шаблонах.

А чего ?ver={{ fc_core.version }} не через бандл?

На выходе сейчас даже было ?ver=***?ver=***, но я убрал уже (в шаблоне). Через бандел у меня почему-то не вышло сначала, но настройку оставил, в итоге там дважды версия выводилась. Я в спешке делал из дому, после релиза новой версии, не глянул, наверное что только в проде добавляется версия ...

А js/base.js через грант или галп собрать. Да и можно ещё посмотреть, что такое бовер.

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

 

[keltanas]

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

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

Да и ларавель туда же. Пока сам все не перешишешь, будешь долго материться, потому что везде одни костыли. Костыли-то я и сам умею делать. А зачем такой фреймворк, в котором надо переписывать абсолютно все? (Я за версию 4 пишу, но на 5ю время тратить не хочется).

ЗЫЖ PHP-фреймворк - он должен предоставлять готовый код на PHP. А если надо с темами, стилями, скриптами и админкой, это можно джумлувордпрессбитрикс взять. Там все есть, бери и пользуйся
Но, я бы все равно лучше грантом

Если у тебя рест апи, то нафик симфони, да и вообще, стоит подумать а нужен ли в таком кейсе php.

Возможно. Я думаю над этим каждый день. Пробовал Торнадо, пробовал Экспресс. Но, на симфони получается как-то привычнее и быстрее (в смысле, скорость разработки и модульность кода). Симфони - это уже целая экосистема. Уже решено много типовых проблем и решения можно найти на стековерфлоу.
Да, в симфони есть проблемные места, но можно научиться не натыкаться на них (Например, соната, или модуль форм, или тот же ассетик=)).

 

[scorpion-ds]

(Например, соната, или модуль форм, или тот же ассетик=)).

Соната это боль, мой первый проект на Сифони написан с Сонатой, самое страшное там это МедиаБандел, он очень тормозит и очень неудобен в плане наполнения сайта. Хуже может только PageBundle, но я его не осилил, 1,5 года назад не нашел вменяемой документации по нему.

Насчет форм расскажите, что с ними не так? Я их использую, вроде вполне удобно, особенно валидаторы.

Вот что мне кажется слишком замудренным, так это авторизации и аутификация, что бы внести свои правки, надо кучу кода переопределить и пересвязать.