О вендорах
В движке используется ряд библиотек, которые необходимы для его работы. Однако множество плагинов и даже шаблонов используют еще какие-то библиотеки. Порой бывает так, что несколько плагинов подключают одни и те же библиотеки. Из того что припоминаю — это какие либо элементы jquery-ui, не входящие в движок, либы для стилизации чекбоксов например, choosen-ы всякие.
В этой связи есть предложение:
1. Выбрать в сообществе голосованием список таких вендоров
2. Включить их в движок
3. Подключать только те, которые необходимы для работы движка и дефолтного скина
4. В админке дать возможность подключать другие либы из списка
5. В плагины и сторонние скины добавить параметр зависимости required vendors
6. При активации плагинов выдавать msg типа: «для работы этого модуля необходимо подключить следующие библиотеки:… с указанием версий»
4-й пункт можно «проапгрейдить» и через какой-нибудь созданный репо со скриптами «стандартизации» под LS подгружать либы с их источников или cdn-ов. «Стандартизация» будет заключаться в расположении директорий и проверку на конфликты библиотек друг с другом.
В этой связи есть предложение:
1. Выбрать в сообществе голосованием список таких вендоров
2. Включить их в движок
3. Подключать только те, которые необходимы для работы движка и дефолтного скина
4. В админке дать возможность подключать другие либы из списка
5. В плагины и сторонние скины добавить параметр зависимости required vendors
6. При активации плагинов выдавать msg типа: «для работы этого модуля необходимо подключить следующие библиотеки:… с указанием версий»
4-й пункт можно «проапгрейдить» и через какой-нибудь созданный репо со скриптами «стандартизации» под LS подгружать либы с их источников или cdn-ов. «Стандартизация» будет заключаться в расположении директорий и проверку на конфликты библиотек друг с другом.
15 комментариев
name = 'jquery.scroll'). При таком подходе исключается загрузка двух и более библиотек с одинаковым названием.Все что нужно, это чтобы разработчики следовали этому.
движок требует библиотеку 1 версии (она входит в него), плагин А — второй (содержит), плагин Б — третьей (содержит).
Вот движку нужно загружать библиотеку последней, 3-й версии из плагина.
Вся демагогия сводится к алгоритму выбора одной копии либы из нескольких. Текущий алгоритм выбирает первую объявленную. Ты предлагаешь выбирать последнюю версию. Оба варианта не гарантируют работоспособности и в конфликтных ситуациях нужно разруливать вручную — проставлять флаг
replace=trueи приоритетной копии. Но твой вариант дополнительно потребует усложнения логики — необходимо проставлять версии, каким то образом учитывать либы без проставленных версий.Вопрос в целесообразности этого, если все равно придется руками отметить нужную копию.
Движок может делать запросы на источник либы и подгружать (точнее добавлять) новую версию автоматом. Своего рода репозиторий. Это, наверное, дело отдельного модуля…
А в required плагинов указывать также требования к версиям библиотек:
<required> <vendors> <vendor name="superjs" version="1.0.0" condition=">=">SuperJS</vendor> </vendors> </required>и при активации админка выдает msg — соответствуют ли требования плагина с вендорами движка.
Что касается конфликтов версий — то эта проблема (риск) существует и сейчас, если разные плагины используют одни и те же либы разных версий, поэтому и предлагаю возможную логику решения.