Каков правильный способ добавления библиотек CSS или JS в качестве зависимостей с Composer в Symfony2?

Ответ 1

Вы можете использовать Bower Twitter. Это менеджер пакетов для HTML, CSS и Javascript. Он был создан для решения этой самой проблемы.

Ответ 2

EDIT: На данный момент есть очень хорошие менеджеры пакетов для JS-библиотек, таких как Bower, Jam или Component.

Система версий

Семантическая версия - Композитор советует использовать семантическую систему управления версиями. Он использует настройку X.Y.Z, в которой X является основной версией, Y - младшая версия, а Z - версия патча. Y и Z всегда должны быть обратно совместимы, в то время как X отражает изменения в коде, которые МОЖЕТ нарушать обратную совместимость.

Embeding

Вставка должна быть прочитана как копия и вставка кода (и двоичного) как часть вашей библиотеки, а затем требующая его как пакет/пакет стороннего поставщика (поставщика). Это похоже на query.js в папке с ресурсами или копирование и вставка кода продвижения в папку внутри вашего пакета.

Почему бы не вставлять сторонние библиотеки

Пакет не должен вставлять сторонние библиотеки, написанные на JavaScript, CSS или на любой другой язык.

Это утверждение происходит с точки зрения лучшей практики. Встраивание (как в copy/paste) сторонних библиотек любого типа (особенно в PHP libs) обычно не является хорошей идеей. Например, представьте, что BUNDLE A использует LIBRARY FOO v1.4.1, а BUNDLE B также использует LIBRARY FOO, но с другой версией v1.5.2. Если какой-либо из BUNDLES (A или B) внедряет FOO lib, они могут (скорее всего, станут) несовместимыми. Например, классы и функции php нельзя переопределять. Любой из пакетов может, конечно, использовать обходные пути для смягчения этой проблемы, такие как namespacing их версии FOO или правил автозагрузки, но это может вызвать другие проблемы, кроме того, что, безусловно, увеличивает использование памяти, так как есть две версии одной и той же вещи, проанализированной по PHP.

Если пакет PHP не соответствует этой наилучшей практике, возникающие ошибки обычно легко обнаруживаются (с ошибкой: не может функция redeclcare blablabla). Однако с библиотеками Javascript это неверно. Вы можете повторно использовать функции (поскольку они являются объектными свойствами). Итак, если теперь FOO - это JS Lib, а BUNDLE A и B внедряют их в свои библиотеки, когда они включены, могут возникнуть странные проблемы. Например, функция может быть переопределена, которая не имеет критической функциональности для одного из пакетов и разбивает ее.

Symfony - это фреймворк PHP.

Он имеет дело с библиотеками/пакетами PHP. Symfony советует требовать библиотеку в качестве зависимости, а не встраивать ее, поскольку она использует Composer в качестве менеджера пакетов, который занимается загрузкой и загрузкой пакетов требований. Насколько я помню, когда 2 пакета/пакеты используют одну и ту же библиотеку, если у них разные требования к версии, используется самая актуальная, если только ее обратная совместимость несовместима. Затем Composer сообщает о конфликте, который необходимо разрешить вручную.

Однако... Невозможно правильно обрабатывать библиотеки JavaScript. Это потому, что Composer является пакетом для библиотек PHP. Вы можете обойти это двумя способами , о которых я могу думать: (есть, вероятно, больше и лучшие способы справиться с этим, я просто думал об этих двух, читал их как предложения)

• Создайте оболочку PHP вокруг библиотеки javascript и включите ее (хотя это потенциально создает ту же проблему, если другой комплект решает сделать то же самое, но придает пакету другое имя)
• Создание пакета, для которого требуется библиотека javascript в качестве сторонней зависимости с помощью композитора. Поскольку в javascript-библиотеке, вероятно, не будет файла composer.json в его репозитории (иногда они живут как автономный файл с миниатюрами), это можно сделать, создав (например, в gitHub), добавляя к нему композитор .json и т.д. Однако вам нужно постоянно поддерживать и обновлять указанную библиотеку, что может быть неприятно.

Вам нужно иметь в виду, что:

• JS и CSS libs должны публиковаться публично, чтобы клиент мог получить к нему доступ (соображения безопасности)
• Symfony - это фреймворк PHP и имеет дело с пакетами на стороне сервера. JS/CSS - это клиентская сторона. Это необходимо учитывать, поэтому оно работает правильно.
• Одна из основных идей Symfony (как и в других PHP Framework) - повторное использование кода внутри и между проектами. Чистая библиотека Javascript может использоваться повторно. Они, как правило, самодостаточны. Кроме того, нет реального выигрыша в "объединении" библиотеки JS со стороны сервера. Вам не нужен какой-либо комплект для достижения повторного использования.

Мой подход

Поскольку система композиторов настолько привлекательна, особенно при развертывании пакетов/пакетов/библиотек для других людей, мой подход к использованию сторонних библиотек javascript/css заключался в создании менеджера менеджера зависимостей, характерного для JS/CSS, которые другие пакеты/пакеты могли бы использовать, чтобы заботиться о своих зависимостях JS/CSS, не беспокоясь об этом.

Мой sugestion

Если вы планируете опубликовать свой проект для общественности, а именно в виде пакета symfony, вы должны тщательно спланировать, как подойти к этому. Если ваш проект является самодостаточным (личное использование или клиент, а не широко распространенное использование), то это имеет гораздо меньшую актуальность, поскольку вы (программист) имеете полный контроль над тем, какие сторонние инструменты вы используете и включаете в свой проект. Это просто лучшие "рекомендации", чтобы избежать будущие проблемы.