Yii 2.0: не скачиваем клиентские пакеты
6 апреля 2016
При разработке Yii 2.0 мы сделали ошибку, включив в ядро по умолчанию клиентские пакеты вроде jQuery. В большинстве случаев это не доставляет проблем, но вот когда разрабатывается исключительно API, а пакеты всё-равно скачиваются и занимают место, возникает некое чувство дискомфорта.
В 2.1 мы попробуем это решить, а пока можно воспользоваться средствами Composer прописав следующее в своём главном composer.json
:
"provide": { "bower-asset/jquery": "*", "bower-asset/jquery.inputmask": "*", "bower-asset/punycode": "*", "bower-asset/yii2-pjax": "*" },
UPD: есть и в готовом виде: https://github.com/cebe/assetfree-yii2
Комментарии RSS по email OK
Так провайд же всё равно выкачает пакеты? Нужно replace использовать, чтобы композер не скачивал эти пакеты. И самый раздражающий момент не в том, что скачиваются эти пакеты, а в том, что fxp каждый раз читает базу бавера для проверки обновлений. Из-за чего в самом простом случае обновление пакетов с 10-15 секунд возрастает до минуты. Пустая трата времени.
rmrevin, без него тоже можно. С конфигом выше сработает.
Composer для composer.json, Bower для bower.json, и т.д. Зачем еще один костыль?
Для зависимостей определённых версий PHP-библиотек на определённые версии JS-библиотек и автоматической установки расширений.
Дак так ведь и получается: каждый репозиторий с пакетом будет содержать composer.json и bower.json. Везде указаны зависимости и версии пакетов. Вот только каждый будет заниматься своим делом, и не лезть другому "в душу".
Василий, умгу, только руками придётся прописывать себе все клиентские зависимости расширений. Скорее всего, к этому и придём...
Может быть стоит подумать над каким-то расширением, которое позволило бы автоматически скачивать и устанавливать клиентские библиотеки из bower.json/packages.json через специальную консольную команду. Как например в ларавел есть спец.команда assets:publish или типа того.
Понятно, что тут есть над чем поразмышлять, но просто сказать, что мол ребята, скопируйте зависимости руками - это не дело. Вообще, был ли анализ того, как решен вопрос в других фреймворках?
Павел, конечно был. Другие PHP-фреймворки, чаще всего, не решают проблему никак. Они просто не лезут в фронтенд.
Sam,
Исходя из всего того, на что я натыкался в Yii2, я думаю это правильно. Если что-то нужно, можно сделать в виде расширения.
Кстате в Yii2.1 планируется выпилить весь фронт в отдельные пакеты ?
Nepster, да.
А насколько 2.1 будет совместим с 2.0, будет ли возможность обновления?
Да поддерживаю вопрос об обратной совместимости 2.1
Мы, например, все зависимости фронта решаем через npm, так что пришлось просто добавить bower-assets в исключения ide и смириться. Без этой шляпы было бы лучше. Если поставлять отдельно bower.json и package.json, а разрабы пускай используют что им нравится, не маленькие.
Обратной не будет, на то и major-релиз, но общего у него будет намного больше, чем у 1.1 и 2.0. Прямо переписывать всё-всё не придётся.
Самой большой болью на текущий момент является fxp/composer-asset-plugin.
Он конечно свою задачу выполняет, но то, как он тормозит composer update при большом количестве пакетов - это надо видеть.
Смешивать ассеты и фреймворк - это имхо само по себе ошибка, от этого и боль. Да, хочется чтобы все работало вот прям из коробки. Но давайте не будем уже совсем считать разрабов без рук и мозгов. Напишите, что для работы компонента нужно прописать путь до ассета, пускай это будет в зависимости, пускай компонент кидает exception, если не задан ассет, но как и куда его положить - это дело разработчика. Можт у меня jquery с cdn, мож он на static сервере отдельном валяется, я его с npm/ bower, что там еще придумали тяну. Или вообще нафиг это API и нет там никаких ассетов. Как-то так вот хочется закричать, когда yii2.0 видишь. Извиняюсь за эмоции)
mrsombre, CDN, статика с отдельного сервера, npm и bower. А также сборка grunt-ом и gulp-ом — это всё делается и довольно легко. Но мысль выкинуть ассеты вообще и переложить всё это на разработчика, конечно, появлялась и продолжает.
Спасибо за заметку, Саша, мне это нужно бывает. Помню, 2ку планировали выпускать "голой", а остальное ставить пакетами. Что-то не пошло?
gri, пошло, но не полностью.
Тут некоторая неточность, как мне кажется.
2.0 -> 2.1 это минорный релиз. 1.1 -> 2.0 — мажорный.
Минорный релиз подразумевает сохранение обратной совместимости, и только добавление новой функциональности.
Мажорный релиз — отсутствие обратной совместимости. Есть ещё вариант объявления, в промежуточной минорной версии, чего либо deprecated, с выбросом ошибок / логированием соответствующим, и уже удалением в последующих минорных обновлениях. ЕМНП, по semver. Т.о.:
Sam, а не планируется ли взаимодействие с Gulp или другими сборщиками? Возможно есть уже наработки или это оставляете на плечи разработчиков проектов (просто интересно)
Евгений Куликов, оставляем на плечи.
Sam, понял, благодарю.
Защита пробита судя по последним комментариям. Александр, похоже пора капчу менять.
Samizdam, похоже да :)