Прошлым летом, пока я прокачивал знание JavaScript и читал документацию Vue.js, наткнулся на видео Криса Фрица:
Один из приёмов, который описывает Фриц — автоматический импорт базовых компонентов: делаешь простенький индексный файл, он пробегает по остальным файлам в директории и регистрирует их как компоненты Vue.
Я обрадовался и рассказал о своей находке коллеге-бекендеру: просто складываешь компоненты в директорию и используешь по всему проекту. Он меня обругал и сказал, что за неявный импорт бьют по рукам. Мы немного поспорили и остались каждый при своём.
Личный опыт
Прошло полгода, и я добрался, наконец, до самостоятельной конфигурации вебпака. Мне нужен был простой сборщик: руками делать лень, а тащить vue-cli или create-react-app для простой страницы — избыточно. Я же хотел максимально облегчить себе жизнь и сделать проект поддерживаемым.
Итак, мне нужно разделять код на модули, но при этом не импортировать каждый создаваемый модуль ручками. Ещё я хочу использовать глобальные переменные в SCSS, клеить и оптимизировать векторные спрайты, использовать современный JavaScript и другие удобства. Как всё это устроить? И тут я вспомнил про автоматический импорт.
Полчаса ушло на то, чтобы освежить информацию и настроиться. Итог — готовый конфиг для вебпака. Попутно попробовал PostCSS, но решил все-таки не пересаживаться на новую технологию: во-первых, мне не нравится синтаксис PostCSS; во-вторых, это бессмысленно, ведь знакомый и удобный SCSS отлично справляется со своими задачами.
Я использовал node-sass-glob-importer для импорта директорий в SCSS:
@import './components/**/*';
@import './shared/**/*';Попробовал использовать — показалось удобным, но решил все-таки посоветоваться с коллегами.
Неявные проблемы
Иду на кухню на работе, рассказываю коллегам и упоминаю, что бекендеры бы за неявный импорт наругали. Завязывается разговор, и опытный коллега-бекендер объясняет мне, чем плох неявный импорт:
— Проблемы возникнут, — сказал он, — когда другой человек посмотрит на код. Он попросту не поймёт, откуда тянется, например, переменная в SCSS. Изучив структуру, можно найти, что это переменная из директории shared. Но у разных людей на это уйдет разное количество времени и нервов.
И тут я вспоминаю свои эмоции, когда распутывал подобные клубки слишком абстрактного кода. И понимаю, что не хочу для коллег таких мучений.
return R.defaultTo(this.isActive, this.visibility);
// Убираю функциональную библиотеку Ramda из проекта
return this.isActive || this.visibility;К разговору подключился ещё один наш разработчик — фронтендер, и рассказал, как они работают с глобальными переменными в SCSS. Ребята разбивают на файлы группы переменных: цвета, брейкпойнты, размеры шрифтов, анимации и прочее, а затем импортируют их в общий файл _settings.scss. И уже этот единственный файл отправляют в компоненты. Удобно.
Убираю автоматическую сборку глобальных переменных и делаю по совету ребят. Оставляю только автоматическую сборку компонентов — лень импортировать в main.scss каждый создаваемый модуль.
На реальном проекте возникают проблемы: при включенном дев-сервере вебпак не подхватывает свежесозданный файл в директории с автоимпортом. Дело в том, что в режиме слежения вебпак наблюдает над изменениями в дереве зависимостей, и строка @import './components/**/*'; в файле main.scss преобразовывается плагином node-sass-glob-importer в пачку строк импортов:
@import './components/all.scss';
@import './components/button.scss';
@import './components/checkbox.scss';
@import './components/form.scss';
…Но в этой пачке нет нового файла, ведь main.scss не менялся. Нужно перезапускать дев-сервер или пересохранять main.scss.
Что всё это значит?
На первый взгляд, автоматический импорт крутая штука, но на деле всё не так радужно. Кратковременное удобство для одного разработчика не стоит времени и нервов остальной команды.
