"Фронтовая" часть должна обеспечить простую и ненавязчивую возможность использования в шаблонах сайтов/компонентов, а также вне их (если очень сильно надо) следующих модных штук:
[x] обработка файлов стилей с помощью PostCSS: 8ab018afac91131a4672af1fe3c4547de4f8b4ce и 5d20e9344ccc381aa5d092d52657fa52b64baab0
[x] генерация png-спрайтов bbb3262
[x] генерация xml-спрайтов (символов)
[x] оптимизация изображений 8248cdca
[x] современный javascript (es6) e34000658bd
[x] Live-Reload сервер (browsersync) 90f0679e23
[ ] ???
[x] PROFIT
При этом не должны требоваться дополнительные настройки, например, при добавлении нового шаблона сайта.
Для этого необходимы соглашения по структуре и именованию.
Наш галп-таск (или нпм-скрипт (или еще чего)) должен "ходить" по всему проекту и искать директории вида assets-raw, обрабатывыать их содержимое и складывать результат в соседнюю директорию assets-done.
Наименование директорий для исходников и результатов сделать конфигурируемыми.
Скрипты и стили полученные данным способом должны подключаться перед "стандартными" скриптами и стилями, для того чтобы была возможность "по-быстрому" поправить какой-нибудь косяк без участия системы сборки и не потерять данный фикс при ее (сборки) запуске.
(Спорный пункт, потому как есть еще composer'ная директория vendor) Директории с результатами по-умолчанию не должны игнорироваться системой контроля версий. Это позволит убрать из скрипта деплоя шаг по сборке и всегда иметь готовый к использованию код проекта.
"Фронтовая" часть должна обеспечить простую и ненавязчивую возможность использования в шаблонах сайтов/компонентов, а также вне их (если очень сильно надо) следующих модных штук:
При этом не должны требоваться дополнительные настройки, например, при добавлении нового шаблона сайта.
Для этого необходимы соглашения по структуре и именованию.
Наш галп-таск (или нпм-скрипт (или еще чего)) должен "ходить" по всему проекту и искать директории вида
assets-raw
, обрабатывыать их содержимое и складывать результат в соседнюю директориюassets-done
.Наименование директорий для исходников и результатов сделать конфигурируемыми.
Скрипты и стили полученные данным способом должны подключаться перед "стандартными" скриптами и стилями, для того чтобы была возможность "по-быстрому" поправить какой-нибудь косяк без участия системы сборки и не потерять данный фикс при ее (сборки) запуске.
(Спорный пункт, потому как есть еще composer'ная директория
vendor
) Директории с результатами по-умолчанию не должны игнорироваться системой контроля версий. Это позволит убрать из скрипта деплоя шаг по сборке и всегда иметь готовый к использованию код проекта.