Frontend Starter Kit

Заготовка для старта работ по фронтенду. Содержит следующие наработки:

• Система сборки на Gulp + Webpack.
• Заготовка для компонентной архитектуры.

Начать пользоваться

• npm run dev или npm run build - Девелоп сборка с source maps
• npm run dev-watch - Девелоп сборка с source maps и watch изменений
• npm run prod - Прод сборка без source maps и с минификацией

Файловая структура исходных файлов SRC

• assets - статичные файлы для проекта (изображения, статичные аудио и видео файлы)
• components - компоненты проекта и конфигурация.
  • config - юазовая конфигурация стилей и шрифты
  • helpers - полезные классы для разработки
  • ui - компоненты интерфейса
  • utils - утилиты для разработки
  • config.scss - Входная точка для конфигурации стилей и шрифтов
  • helpers.scss - Входня точка для вспомогательных стилей
• entry - Входные точки приложения
  • common.js - Общие скрипты и стили для всех проектах на заготовке (конфиграция стилей, шрифты, вспомогательные классы)
  • main.js - Входная точка для компонент приложения
• twig - шаблоны верстки. В корне каталога находятся страницы. Layout и части страниц нужно размещать в подкаталогах.

Файловая структура конечных файлов DIST

• *.html - скомпилированные корневые twig шаблоны
• assets - CSS и JS билдятся для каждой входной точки и дополнительно собираются общие чанки CSS и JS между котрольными точками и дополнительно выделяются чанки для вендоров (по правилам https://medium.com/webpack/webpack-4-code-splitting-chunk-graph-and-the-splitchunks-optimization-be739a861366), например:
  • common.js и main.js - сбилженные скрипты.
  • common.сss и main.css - файлы стилей из зависимостей входных точек
  • commonmain.css и commonmain.js - Общие стили и JS для входный точек common и main
  • vendorscommonmain.js, vendorscommon.js, vendorsmain.js - вендорские зависимости из node_modules для входных точек (вместе, по отдельности, попарно и т.п.).
  • и т.п. по новому optimization.splitChunks

Дополнительно

• Изображения из assets/images проходят оптимизацию под Google Page Speed
• Линтинг стилей и кода по-умолчанию не включен в сборку, но в заготовке присутствуют файлы конфигураций для него. Как добавить линтинг в сборку, описано ниже.

Линтинг стилей

Мануал, как настроить линтинг стилей в проекте и интегрировать его в webpack

• Шаг 1. Убедиться что у тебя PHPStrom самый мажорный (на декабрь 2016-го - чтобы нативно поддерживать stylelint и видеть ошибки сразу во время разработки )
• Шаг 2. Установить stylelint глобально: npm i -g stylelint. Только надо быть осторожным, ибо версия 7.7.0 почему то не работала для IDE (в модуле не было дирреткории dist с файлом cli.js), в момент написания этой статьи я использовал версию 7.5.0. Возможно это фича, стоит разобраться подробнее. Если PHPStorm ругается на пакет и отсутствие файла cli.js - ставим другой пакет
• Шаг 3. В корне проекта создать файл .stylelintrc, в котором и будут записаны правила (либо просто используем файл из этой заготовки)
• Шаг 4. Идем в настройку PHPStorm,

file->settings->languages&frameworks->stylesheets->stylelint, 

и делаем enabled прописав верные пути до NodeJS и пакета stylelint На этом моменте PHPStorm начнет подсвечивать ошибки в редакторе и показывать сообщения об ошибках при наведении http://prntscr.com/dmxaeu
Поскольку это нифига не информативно и мы не хотим чтобы люди просто забивали на эти ошибки, то надо интегрировать stylilint в сборку webpack, чтобы проверка на ошибки проходила еще и в момент сборки и ошибки сыпались в консоль (либо вообще сборка не проходила при наличии ошибок, так тоже можно).

Интеграция с webpack уже проведена, ниже мануал, как это было сделано

• Шаг 1. Ставим самый актуальный stylelin плагин для webpack по его мануалу https://www.npmjs.com/package/stylelint-webpack-plugin. Он смотрит все файлы в проекте по-умолчанию, а не те, которые в сборке, но другие актуальные плагины на грани deprecated и рекомендуют использовать именно этот плагин.
• Шаг 2. В конфиге для stylelint-webpack-plugin обязательно прописываем путь до наших файлов, чтобы он смотрел только их. В примере ниже это все sass и css файлы. Выборка зависит от регулярки, поэтому как настроем, то и будет проверяться.

var StyleLintPlugin = require('stylelint-webpack-plugin');

/* ... */

plugins: [
new StyleLintPlugin({
    files: ['frontend/src/components/**/*.s?(a|c)ss']
})
/* .. */
]

Подключать нужно до CommonChunkPlugin, иначе шрифты не будут раскидываться куда надо. По крайней мере на Элекарде так и было, шрифты не клались в дирректорию fonts с помощью webpack, пока я плагин stylelint не перенес самым первым. Кстати, заметил я это только с помощью тестов, когда решил "на всякий случай прогнать сайт", хотя и не подозревал что может что-то сломаться.
Собственно теперь ошибки будут высвечиваться во время сборки. Специальными параметрами плагина stylelint-webpack-plugin можно вообще запретить сборку при наличии ошибок, но это какая-то крайняя мера.

##Автоматическое форматирование файлов стилей согласно конфигурации Когда нужно привести в порядок 100500 файлов в проекте и совершенно не хочется делать это вручную, то идем вот сюда https://github.com/morishitter/stylefmt (эти ребята официальные представители автофиксов для stylelint) и выполняем следующую процедуру:

• Шаг 1. npm i -g stylefmt
• Шаг 2. Из корня проекта выполняем stylefmt -r frontend/src/components/ui/**/*.scss, только пусть соответственно до наших файлов и scss, less, css тип файлов соответственно.

Этот форматтер сам найдет файл конфигурации правил в проекте и подгонит форматирование стилей под эти правила. К сожалению, не все правила поддерживаются этим форматтером. Список файлов приведен в их readme на github. Остальные правила придется форматировать вручную

Линтинг JavaScript с помощью ESLint

Включаем ESLint в PHPStorm

http://prntscr.com/dt8ud6 Идем в настройки, в поиске вбиваем eslint, кликаем по пункту меню, делаем enable, указываем путь до пакета ESLint (глобально или локально - по-желанию), оставляем автоматический поиск (принцип поиска как node_modules в nodeJS - поднимается вверх по каталогам). Все, после этого редактор подсвечивает ошибки из правил линтера http://prntscr.com/dt8v8p

Включаем линтинг JS в сборку

1. Ставим вот этот плагин https://www.npmjs.com/package/eslint-loader
2. Указываем в конфигурации webpack линтер как preloader, исключая папку вендоров, чтобы на нее не распространялись наши правила

    module: {
                preLoaders: [{
                    test: /\.js$/,
                    loader: "eslint-loader",
                    exclude: [
                        /node_modules/,
                        /vendor/,
                        /backend/ //чтобы не линтить то, что в backend
                    ]
                }],

Ставим в качестве именно прелоадера, чтобы линтить при сборке исходные файлы, а не файлы после обработки 3. Убираем NoErrors плагин из webpack new webpack.NoErrorsPlugin(), иначе этот плагин не будет собирать нам сборку до тех пор, пока в консоли есть сообщения об ошибках, а это не всегда бывает нужно 4. Теперь при сборке видим ошибки и предупреждения, как и хотели http://prntscr.com/dt9k6u

Автофикс на основании правил линтера

Правила http://eslint.org/docs/rules/, у которых стоит иконка "fixable" могут быть исправлены автоматически, для этого запускаем в консоли eslint для наших файлов с ключом --fix

eslint frontend/src/components/ui/**/*.js --fix

Чтобы React врубить

https://www.npmjs.com/package/eslint-plugin-react