Структура проекта для препроцессоров

[spo]

Привет, всем.

Относительно недавно, решил расширить свои навыки, применением препроцессоров, систем автоматизации сборки проектов и других инструментов, уже давно переставших быть чем то новым в мире верстки и фронтенд разработки.

И хотя, для большинства проектов с которыми я сталкиваюсь, использование всех этих технологий вместе не всегда оправдано, мне все же хочется подготовить более-менее универсальную систему, в которой собрать все изученное в теории, за последнее время.

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

В русскоязычном сегменте интернета, существует не так много информации на эту тему. Вот что мне удалось найти:

• Организация кода для CSS препроцессоров
• Организация кода для CSS-препроцессора
• Организация кода для HTML-препроцессоров

В данных статьях относительно подробно все рассмотрено, но мне хотелось бы немного больше. А именно:

• определиться, на какие составные части, в том или ином случае, разбивать структуру и оформление для html и css препроцессоров;
• разобраться с внутренним устройством файлов (как, где и в каком порядке все это подключается и собирается);
• а так же, вообще, лучше понять возможности и нюансы использования препроцессоров.

Думаю, что лучше всего, в понимании этих тем, могли бы помочь реальные примеры чужих работ, по этому, если кто то может, прошу поделиться ссылками на github.

[spo]

Определился со структурой.
Решил разбивать все максимально подробно. Не для каждого проекта это потребуется, но зато упростить потом смогу и сам, а вот с расширенной структурой есть ряд вопросов.

Начну со стилей.

Структура проекта в папке /source следующая:

• /helpers
  • _reset
  • _vars
  • _mixins
  • _base
  • main - содержит @import _reset, _vars, _mixins, _base
• /components
  • /nav
    • _media
    • styles - содержит @import _media
  • /page_home
    • /sidebar
      • _media
      • styles - содержит @import _media
• /pages
  • home
    • _media
    • styles - содержит @import _media

'use strict';

const gulp = require('gulp')
	, sass = require('gulp-sass')
	, sourcemaps = require('gulp-sourcemaps')
	, concat = require('gulp-concat')
	, autoprefixer = require('gulp-autoprefixer')
	, cssnano = require('gulp-cssnano');

/* path */

const path = {
	styles: {
		source: {
			main: './source/helpers/main.sass',
			components: './source/components/**/*.sass',
			pages: './source/pages/**/*.sass'
		},
		build: './build/css/',
	}
}

/* tasks */

gulp.task('sass', function() {
	return gulp.src([path.styles.source.main, path.styles.source.components, path.styles.source.pages]) // Последовательность чтения и обработки (для конкатенации в определенном порядке)
		.pipe(sass()) // Компиляция кода препроцессоров
		.pipe(sourcemaps.init()) // Инициализация sourcemaps
			.pipe(autoprefixer({ // Обработка автопрефиксером
				browsers: ['last 3 version']
			}))
			.pipe(cssnano()) // Минимизация
			.pipe(concat('main.min.css')) // Конкатенация всех файлов в один
		.pipe(sourcemaps.write()) // Запись sourcemaps
		.pipe(gulp.dest(path.styles.build)); // Выгрузка в build-каталог
});

1. Из-за расширенной структуры, где стили расположены в разных местах, стоит задача объединить их в нужном порядке.
Для этого мне пришлось написать такой страшный path и gulp.src Нормальная ли это практика или есть более правильный способ?

2. Есть ли разница (например в производительности) в обработке файлов до конкатенации и после?

3. Нужно ли обрабатывать файлы js-плагинов (стили, скрипты) и объединять в основные файлы (build/css/main.min.css и build/js/scripts.min.css соответственно)? Если да, то как быть с файлами изображениями js-плагинов? Выгружать в build/img?

[destus]

1. А зачем стили подгружать в определенном порядке? Там где что-то конфликтует, можно разрешать через !important.
2. 3 маленьких бандла и 3 запроса на сервер или 1 большой файл и 1 запрос на сервер. Я выбираю второй вариант.
3. Нужно. И картинки тоже нужно прогонять через вспомогательные модули типа pngquant, которые пару кб тебе сэкономят. В идеале папка build должна форсироваться динамически, которую сразу можно выложить на продакшн.

[spo]

1. А зачем стили подгружать в определенном порядке? Там где что-то конфликтует, можно разрешать через !important.

Не совсем понял про !important.
А стили подгружать нужно в определенном порядке чтобы по порядку шли: reset, vars, mixins, base и далее все остальное

UPD: Кажется я вас понял вы имели ввиду @import а не !important
Я могу попросить вас перечитать мой вопрос или повторить его еще раз. У меня стили расположены в разных местах. В одном месте есть основной файл main который при помощи @import собирает reset base итп. В других местах содержаться другие стили, например components/nav/styles.sass содержит стили а так же @import _media Таким образом при компиляции sass я получаю множество файлов стилей в разных местах. Вот эти файлы затем я и конкатенирую и на этом шаге мне важна их последовательность. Наверное можно все файлы стилей компонентов вручную при помощи @import вставлять в основной файл, но зачем если можно автоматизировать.

2. 3 маленьких бандла и 3 запроса на сервер или 1 большой файл и 1 запрос на сервер. Я выбираю второй вариант.

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

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

Как бы не совсем то что я спрашивал. Мой вопрос в том нужно ли файлы модуля js (стили, скрипты, картинки) обрабатывать и раскидывать по папкам в build

[spo]

Товарищи, пожалуйста подскажите.

[destus]

Наверное можно все файлы стилей компонентов вручную при помощи @import вставлять в основной файл.

Именно так я бы и делал. Но если вы хотите нужный порядок в gulp.src, указывать, то никто не запрещает. Так делать можно. Я бы не рекомендовал использовать имя переменной "path", потому что есть Node.js модуль path (кстати, странно что вы его не используете), и лучше этой переменной объявлять объект, который он экспортирует

const path = require('path');
const projectPath= {
	...
}
...

А мой вопрос про обработку стилей плагинами. Вначале собрать в файл а потом обрабатывать или обработать на лету а потом собрать в файл.

Обработать на лету, а потом собрать в файл и минимизировать. Потому что до concat, у тебя будут выходить из потоков разные файлы, concat их будет все ждать и потом объединять. И там будет параллелизм, то есть не просто сначала найти все файлы в gulp.src и обработать плагинами, а всё вперемешку.

Нужно ли обрабатывать файлы js-плагинов (стили, скрипты)

Обычно с библиотекой/плагином уже идёт минифицированный/сжатый файл и как-то обрабатывать его не нужно дополнительно.

объединять в основные файлы (build/css/main.min.css и build/js/scripts.min.css соответственно)?

Часто то что написано не нами, объединяют в отдельный файл (vendor), а то что нами в свой (main, app, ...). Это хорошо для кэширования на клиенте. Ну то есть твоё приложение каждую неделю, например, получает новую версию, ты его выкладываешь и юзеры скачивают обновленный код (кстати, где gulp-rev плагин для "умного" кэширования? http://javascript.ru/optimize/cache-...ie-versionnost ). А vendor меняется редко и постоянно будет браться из кэша.

то как быть с файлами изображениями js-плагинов? Выгружать в build/img?

да (gulp-css-url-adjuster)

[spo]

destus, большое спасибо!