Yii, fxp и Asset packagist
12 августа 2016
Когда Composer ещё не стал стабильным, API его довольно часто менялось. Из за этого отваливались плагины. Одним из самых ярких примеров был постоянно ломавшийся fxp/composer-asset-plugin
, используемый в Yii 2.0 и попивший немало крови. С релизом Composer проблема практически ушла, но к Yii 2.1, из за скорости установки и самой необходимости ставить плагин, было решено исследовать альтернативы. fxp, как и прежде, работает не быстро.
Сначала мы начали смотреть в сторону нативной установки при помощи npm и bower, но этот вариант, хоть и очень привлекательный, имеет значительный минус в контексте расширений — не получается удобно связать конкретные версии PHP-пакетов и JavaScript-пакетов.
Андрей Васильев (@hiqsol) примерно в это же время занимался тем же. Исследовав множество вариантов, он пришёл к созданию asset-packagist. По сути это прокси-репозиторий пакетов. Во вне пакеты видны как Composer-ские. Внутри всё тот же fxp обрабатывает пакеты, имена, которых начинаются на bower-asset
или npm-asset
. Работает всё очень быстро. Глобальных плагинов не требует.
Ещё до публичной версии Yii 2.0 мы с Qiang-ом рассматривали такой вариант, но почему-то (уже не помню почему), его отклонили, взяв в работу fxp.
Возможно, в версии 2.1 Yii будет использовать asset-packagist.
Комментарии RSS по email OK
Попробовал у себя на проекте - действительное быстро, оставил!
Мне кажется, или asset-packagist не подтягивает зависимости?
Например для composer require "bower-asset/jquery-ui:^1.12" fxp загрузит и jquery-ui 1.12.0.1, и jquery 3.1.0, а asset-packagist загрузит только jquery-ui 1.12.0.0.
Александр, на чистом проекте воспроизводится? Если да, стоит закинуть issue в github.com/hiqdev/asset-packagist/issues
Возможно стоит провести голосование сообщества npm/bower или расширение для composer
BS, уже проводили в немного меньшем масштабе. Вышло 50/50 то есть в любом случае найдутся те, кто хочет grunt/gulp + bower и те, кто не хочет на своём сервере ноду.
Sam, воспроизводится и на чистом пустом, и на рабочем проекте с различными пакетами. Issue создал.
Что-то я так и не понял предложение: "Сначала мы начали смотреть в сторону нативной установки при помощи npm и bower, но этот вариант, хоть и очень привлекательный, имеет значительный минус в контексте расширений — не получается удобно связать конкретные версии PHP-пакетов и JavaScript-пакетов.", у меня не было каких либо проблем, и этой яне понимаю. В чем соль?
Василий, например, мы делаем расширение-обёртку для HTML-разметки под CSS-фреймворк. Версия в bower 1.0, версия в composer 1.0. Далее у нас выходит версия 2.0 bower-пакета, которая не совместима с версией 1.0. В то же время bower-пакет используется в других расширениях. Composer ситуацию отработает верно потому как и bower-пакеты и composer-пакеты резолвятся его SAT-солвером.
Использую уже на 3 проеках, полет нормальный.
Sam, я считаю, это проблема того самого расширения-обертки. А это очередной костыль. ИМХО.
Василий, что именно проблема расширения обёртки и что именно костыль?
Sam,
костыль
Василий, сейчас такое расширение ставится полностью прозрачно. То есть
composer install
и всё. Оно всё, что ему надо, вытянет само в нужных версиях. В случае, если пакет используется несколькими расширениями (тот же jQuery), версии корректно разрулятся. Если переключиться на нативный bower/npm, так получится?asset-packagist — по сути да, костыль, чтобы без ноды через composer получить доступ к npm/bower пакетам. Часть сообщества категорически отказывается ставить ноду на свои сервера.
Sam, я считаю, что когда возникают конфликты версий - их нужно решать, а не костылить. На моей практике конфликтов пока не было.
Василий, решать как? Если версии в двух разных менеджерах пакетов, решать можно только руками, что очень неудобно.
Sam, да, руками. =) Костыли более как-то не очень. =)
Василий, то есть придётся отсмотреть код всего, что используется, разобраться, какие именно версии какого клиентского пакета требуются какими расширениями. С чем возникают конфликты и т.д. На это уйдёт туча времени.
Sam, почему всего? Разработка ведь выполняется постепенно, а не пачкой. Конфликт появился - разрешили, и т.п. Если какое обновление, то как правило, редко они проходят гладко. И опять же, на моем опыте не было такого, чтобы я изучал код всего. Поэтому, ИМХО, я уже все сказал выше. =)
На начальном этапе активной разработки именно всего. Потом да, можно и руками, хотя время отнимает. Например, обновить тот же самый jQuery в большом проекте — просмотреть CHANGELOG пяти библиотек и погонять их все с новой версией во всех сценариях. Это минимум пол рабочего дня.
Sam, пол рабочего дня для обновления - это нормально, и даже не много.
У всех разные темпы работы, конечно, но, как по мне, это многовато.
Я за то как в ларе, никаких требований использовать ассеты. за все сам отвечаешь, хочешь бовер, хочешь пакажист или фхр.
любой проект на yii, когда еще работал с ним (а ныне безвозвратно ушел, нет не в лару, а в битрикс), любой проект начинал с того, что чистил от всех бутстрапов и пр. благо это не долго, но все равно надоедало. Уже когда то высказывался о том, что этот бутстрап в формате обязательной зависимости к фреймворку - сильно лишнее. я писал апи, но бутстрап все равно тянулся. Нафига?
Всплыла одна не очень приятная проблема. При установке всех зависимостей:
Файл
vendor/yiisoft/extensions.php
не создается и перестают работать некоторые алиасы, например@vova07
,@gii
,@debug
, ...Приходится фиксить github.com/LAV45/yii2-imperavi-widget/commit/7bd5e52bd72800eb22ad6697758d5b641f784fd7
Файл создаётся плагином. В команде выше есть
--no-plugins
. Естественно, что плагин не задействован и файл не генерится.sum, спссибо
Снёс "fxp/composer-asset-plugin". Буду переводить все проекты.
да, нода не нужна