мне больше нравится подход как здесь — https://laravel.com/docs/5.3/elixir
И как это совместимо будет с подходом
TypeScript->JavaScript, Less->CSS, SCSS->CSS?

Я с Elixir не работал, но исходя из того, что это надстройка над Gulp — его можно использовать и с CleverStyle Framework без особых сложностей. Можно либо складывать артефакты туда, откуда их автоматически подхватит фреймворк, либо написать кастомную небольшую интеграцию с помощью обработчиков упомянутых в статье событий.


Я пытался сделать работу со статикой максимально декларативной, то есть вы указываете какой файл (или группу файлов, которая в продакшене конкатенируется в один файл) нужен на какой странице, а обо всём остальном, включая версии и зависимости побеспокоится фреймворк. То есть вам никогда не нужно писать нечто подобное:


<link rel="stylesheet" href="{{ elixir('css/all.css') }}">
<script src="{{ elixir('js/app.js') }}"></script>
мне кажется что
<link rel="stylesheet" href="{{ elixir('css/all.css') }}">
<script src="{{ elixir('js/app.js') }}"></script>

удобнее, чем
"assets"       : {
        "admin/Uploader" : "admin.css",
        "Uploader"       : "script.js"
    },

в куче модулей.
Даже написание задачи gulp для нужных файлов все равно выйдет короче. Я б на вашем месте сделал gulpfile.js с заданием для скриптов/стилей модулей, которые у вас в комплекте идут, может кому понадобится

А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде. В каждом из модулей есть набор CSS/JS/HTML файлов, но перед тем как грузить котиков мне нужен сам функционал загрузки.


В моем случае это будут два модуля, каждый из который имеет в простейшем виде следующее:


{
    "package" : "Kitty",
    "require" : "Uploader",
    "assets" : {"Kitty": "*"},
...
}

{
    "package" : "Uploader",
    "assets" : {"Uploader": "*"}
...
}

gulpfile.js не подходит по идеологическим причинам — CleverStyle Framework не требует на сервере ничего кроме PHP, к тому же все модули опциональные, они в репозитории, но не обязательно в комплекте.


Использование только PHP позволяет делать удобные интеграции всего вместе в том числе с клиентского интерфейса, когда нет доступа к CLI в принципе. Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом, хотя для самого Composer в обычном режиме нужен доступ к CLI, а плагин должен быть установлен глобально.

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

такое разруливать самому, но случай какой-то странный.
Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом

это конечно круто, но я б отнес к разряду «свистелко-перделок».
Если нет ноды на серваке — то закидывать в cvs скомпилленные ассеты и не придется ничего запускать.
Даже если не используется никакая csv — по фтп закинуть скомпилленные файлы будет проще.
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде.

мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто

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

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

А если зависимость необязательная? К примеру, WYSIWYG редактор — на базовую функциональность не влияет, может как быть, так и отсутствовать. Криво как-то вписывать это вручную в gulp-задачу, да ещё с проверками на наличие файлов.


В том-то и преимущество в CleverStyle Framework — вы не прописываете вручную ничего для использования. Разработчик модуля объявляет всё декларативно во время разработки, после чего достаточно установить модуль, и на основании декларативной конфигурации нужное странице будет подключено и закэшировано как положено.

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

Советов несколько:


  • делите на самостоятельные куски, чтобы подключать только нужное
  • если это JS — выделяйте в AMD модуль и грузите только его (об этом будет отдельный пост)
  • если первые два варианта не подходят — есть вероятность, что лишнего кода не так много и с этим можно жить

Если совсем кастомная ситуация — вы всегда можете дополнить встроенную функциональность фреймворка и интегрировать туда в том числе gulp, если контролируете окружение. Фреймворк не покрывает 100% ситуаций самостоятельно, но оставляет возможности интеграции для покрытия 100% ситуаций при необходимости. Нужно следить за балансом предоставляемой из коробки функциональности.


Вдруг я захочу вместо скрипта от модуля использовать свой?

Вот здесь не совсем понятно что имеется ввиду. Модуль это самостоятельная единица, перезаписывать отдельные файлы тоже в теории можно (подписаться на события установки/обновления модулей и перезаписывать нужный файл поверх, либо подписаться на упомянутое в статье событие и редактировать путь к исходному файлу в маппинге ресурсов), но это уже как-то совсем дико. Какой сценарий имеется ввиду?

редактировать путь к исходному файлу в маппинге ресурсов

это и имеется в виду. Вдруг разработчик модуля слегка криворукий, а модуль все же полезный, мало ли что может быть. Пока работал с вордпрессом — такое бывало.
А так в gulpfile переписал путь и все, исходный файл не тронут
За советы спасибо, но я наверно не так объяснил что имел в виду — как раз визуальный редактор к примеру не нужен в публичной части сайта, а в админке норм

webpack + npm… не надо писать свои менеджеры модулей на php.

Bower/NPM используются и так, а вот Webpack зачем? Node.js на сервере может не быть, работает он медленнее, для интеграции в проект (таким образом, как это описано в статье) всё равно придется написать кучу кода. А так никаких императивных конфигураций не нужно и всё шустро работает. А если Webpack для чего-то нужен, то его можно несколькими строчками интегрировать как готовый сторонний сервис вместо того, чтобы требовать на уровне фреймворка.

Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.