после того как верстка готова, её нужно порезать на шаблоны серверного шаблонизатора
Нет, она уже должна быть адекватно порезана, желательно с учётом серверного шаблонизатора и его структуры. Но (сразу уточню важный момент - я не эксперт по jade/pug и могу ошибаться) jade/pug не имеет многих функций, которые умеют серверные шаблонизаторы, из-за этого (лично мне) приходилось делать работу "наизнанку". В итоге, получилось работы больше, чем без jade/pug вообще.
js и scss исходники раскидать по папкам в какой-нибудь resource директории и настроить сборку всего этого добра тем же gulp и webpack, что бы в дальнейшем проект поддерживался уже без отрыва от серверной части.
настроить сборку по тем же путям, по которым они располагаются на сервере. Мне кажется, это довольно очевидный момент.
Вот с таким пониманием, как я изложил выше, не могу понять пользу от этого модульного подхода после того как этот "полуфабрикат" в виде верстки сдан.
Из личного опыта, пользу получают в основном те, у кого компьютер PHP (или PHP-шаблонизатор) не потянул, или автор не осилил установку PHP или не осилили основы PHP/-шаблонизатора этот человек не осилил. Обычно, гораздо проще писать сразу на PHP-шаблонизаторе, в идеале - в купе (совместно) с проектом и сразу же проверять/видеть результат. В нормальной фирме, программисты ни натягиванием вёрстки, ни её разработкой (созданием) не занимаются, этим занимаются исключительно верстальщики. А теперь подумайте, Вы действительно хотите сначала писать шаблоны в jade/pug, а потом перегонять их в Twig например? Такой подход, как Вы описали, обычно применим для команд уровня "1.5 человека", в которых обычно есть "заказчик" и "исполнитель", при этом, в 95% случаев, заказчика мало интересуют исходники, особенно исходники jade/pug.
Могу Вам порекомендовать ознакомиться с проектом
nodeJS/Twig, в теории это реализация PHP-шаблонизатора Twig на JS'е. Но, сам не пробовал особо, описать впечатления не могу. Возможно, он способен генерировать/интерпретировать правильный Twig-код, который потом можно будет использовать в PHP.
Есть еще мысли, например, хранить эту верстку отдельно, собирать из исходников готовые js и css файлы в директории с серверным проектом и в случае необходимых правок вносить их сначала в самой верстке, а потом дублировать изменения в серверном шаблонизаторе.
Есть такой "паттерн", называется "сборка проекта", появился он (как практика и ПО для реализации подобных практик) задолго до того, как мир узнал слова Gulp, Grunt, etc. Среди прочего, это ПО умеет собирать SCSS, минимизировать JS-код, склеивать/расклеивать/размазывать/итд его (код) любым возможным образом. Это же касается и оптимизации картинок и всего остального.
Почти всё, что Вы видите в виде модулей для nodeJS и/или Gulp/Grunt, включая их самих - в большинстве случаев, есть либо переписанная на JS существующая ранее программа/утилита (для возможности работать на nodeJS), либо, обёртка поверх них. На мой взгляд, Gulp не лучший конвейерный сборщик проектов, для проектов с длительной поддержкой, для языков отличных от JS. Он скорее лучший сборщик для соло-разработки, когда верстальщик и заказчик - это два человека, и длительная поддержка проекта изначально не планируется. У любого крупного и адекватного проекта, обычно есть сборщики альтернативные Gulp/Grunt, а необходимые корректировки пишутся не дважды, а один раз, на одной конкретной ветке проекта. Не редко, специально для этого поднимаются тестовые стенды, не редко их может быть довольно много, и там Вы можете вносить любые изменения в т.ч. и вёрстку и тут же мониторить результат её реального отображения, а потом делать соотв. пуш, соотв. ветки на соотв. сервер/репозиторий и отправлять проекта на тесты/сборку/итд.
Средний
