Небольшая заметка о том, как подключить в webpack и в ваше приложение postCSS с поддержкой SCSS/SASS синтаксиса.

• Устанавливаем npm i --save css-loader node-sass sass-loader style-loader postcss-loader
• Добавляем в webpack.config.js новый loader в раздел module.loaders такую вот цепочку:

  {
    test: /\.scss$/,
    loaders: ['style', 'css', 'postcss', 'sass']
  }
  

• Подключаем в нужном JS-файле стили: import './main.scss'
• Запускаем webpack

Потребовалась вереница loader-ов. В случае необходимости можно ещё понастраивать postcss (см. документацию к postcss-loader-у).

Случилось так, что неудачное обновление YandexDisk-а, либо же их кривые dpkg-скрипты поломали мне пакетный менеджер (dpkg). Его просто парализовало. Пришлось его насильно убивать (sudo killall -9 dpkg), пытаться починить (dpkg --configure -a), но тщетно. Обновил данные с репозиториев (sudo aptitude update), и попробовал просто обновить сами пакеты (sudo aptitude upgrade). Тщетно, оно почти на любой операции дохнет на попытке обработать пакет yandex-disk. Попробовал его remove и purge. Не шмогло оно. Попробовал напрямую через dpkg, тщетно. Попробовал даже чёрную магию (sudo dpkg --remove --force-remove-reinstreq yandex-disk) всё равно зависает. 

Старый добрый stack-overflow подсказал, что в таких случаях нужно править сами install-скрипты. Нужным оказался этот: /var/lib/dpkg/info/yandex-disk.prerm. Внутри буквально 1 строка. В ней killall -qw yandex-disk. Обратите внимание на флаг w. Wait. Оно ждёт смерти yandex-disk, который у меня не был запущен. Ждёт вечно. Руками убрал эти флаги и повторно заpurge-ил пакет. На этот раз всё прошло без запинки.

Дааа. Linux пока ещё сильно далёк от user-friendly интерфейсов. Как бы такую проблему смог бы самостоятельно решить не IT-ик я не представляю.

Столкнулся с неожиданной для себя проблемой. Сборка проекта под Windows шла криво, в то время как под Linux без проблем. Вначале грешил на обратные и прямые слеши (/ & \). Беглый поиск по этой проблематике дал мне понять, что никаких проблем с unix-like слешами под Windows быть не должно. Оказалось, что всё немного хитрее. Я в некоторых местах работах с путями как со строками, игнорируя тот факт, что пути в процессе работы могут быть сторонним кодом преобразованы. 

Скажем был у вас путь path/path/path. В процессе работы какого-нибудь gulp-плагина он исправился на windows-правильный путь path\path\path. А у вас далее по коду какой-нибудь .replace('path/path', ''). И вот оно сломалось. 

В августе сего года заканчивается поддержка GraphAPI 2.0 версии. Facebook уведомляет об этом прямо в своих стандартных уведомлениях соц. сети заголовком %app has a new Developer Alert, за которым следует текст:

%app has been making recent API calls to Graph API v2.0, which will reach the end of the 2-year deprecation window on Monday, August 8, 2016. Please migrate all calls to v2.1 or higher in order to avoid potential broken experiences.

Что именно, касательно OAuth, изменилось? А вот что:

• В graph.facebook.com/… следует добавить v2.6:
  • https://graph.facebook.com/v2.6/oauth/access_token
  • https://graph.facebook.com/v2.6/%uid%/picture
  • etc…
• /oauth/access_token теперь возвращает не queryString, а нормальный JSON

Лет 5 назад я впервые подключал к сайту Facebook SDK, для правильного внедрения like-кнопки и блока с рожицами. По сути было 3 варианта:

• Разместить ссылку с картинкой, которая бы вела на facebook-страницу для share-а или like-а. Самый быстрый вариант, даже, можно сказать, молниеносный, т.к. не нужно ничего грузить. Но такими кнопками пользуются куда реже, чем если они размещены правильно. Т.е. если нужен не факт наличия кнопки, а результат от её использования, то такой вариант отпадает.
• Внедрение через XFBML-разметку. Дело не хитрое. Размести специальный тег куда требуется. Подключи скрипт. Есть варианты. Настройки задаются в виде аттрибутов тегов.
• Примерно тоже самое но сразу через <iframe/>.

Казалось бы дело совсем не хитрое. Но в процессе эксплуатации выяснилось много неприятных подробностей. Дело в том, что like-кнопка после нажатия показывает специальный popup. И этот popup в vk-like и fb-like реализованы по разному. В vk-like панелька показывается нормально вне зависимости от вёрстки, а fb-like панелька сделана ногами и вызывает кучу проблем, если у вас выше по коду установлен какой-нибудь overflow: hidden, или ещё какая-нибудь особенность вёрстки. Помимо прочего, большое значение имеет то, куда вы эту поганую кнопку разместили. Если это нижний правый угол сайта, то попав вылезет не вверх, как стоило бы ожидать, а вниз. И, либо не поместится, либо разопрёт сайт как попало. Настройки "распирайся вверх", разумеется, нет. Честно говоря возможности этих стандартных контролов просто никакие. 

Помимо внешнего вида, проблемы вызывает ещё то, что соц. сети грузят вашу страницу crawler-ом, для добычи мета-тегов, со специфическим набором http-заголовков. И если ваш сайт в такой ситуации падает (ну мало ли какой баг), то без debug-страницы вы долго будете гадать, в чём же блин дело.

После удачной загрузки страница кешируется. В случае VK навсегда (если верить новому API, то уже не совсем), а в случае facebook, кеш страницы всё таки можно сбросить. Есть специальный инструмент, который умеет показывать ошибки выгрузки мета-данных. К тому же можно вызывать его программно (к примеру при замене og:image).

В очередной раз я столкнулся с facebook like кнопкой сегодня, когда узнал, что они не работают в мобильной вёрстке. Дело оказалось не в этом… Думал поправлю за 5 минут, и в итоге убил весь вечер. Слишком много изменений, порой сильно не очевидных. К примеру:

• Теперь like и share кнопки — это 2 разные кнопки,
• Но share-кнопку можно паровозиком прицепить к like-кнопке. Выглядит забавно.
• SDK обновился до 2-ой версии. И она не поддерживает решения из 1-й.
• При этом share кнопка из 2-ой версии работает в 1-ой.
• Но только на desktop-ах. А на мобильниках она просто ставит для <body/> класс со стилями { overflow: hidden; position: relative } и молча, без ошибок, дохнет. Скролл естественно ломается. Счастливого дебага, суки... да? :-)
• Раньше для отображения картинок при like-ах и share-ах достаточно было og:image разметки. А теперь… Она всё та же, но появились ограничения по мин. размеру — 200х200. Портал для которого я это домкратил, для всех своих тысяч постов использует картинки меньшего размера. Спасибо, facebook… гори в аду.
• Facebook поменял своё отношение к некоторым аттрибутам к <html/>. Вплоть до ругани красным из-за какой-нибудь ерунды.
• Усердно ругается, если используются аттрибуты name вместо property в <meta/>-тегах.

Подлатал, поправил, переделал. Теперь вроде всё работает. Полагаю, что спустя пол-года они снова в одностороннем порядке что-нибудь изменят и всё сломается. В который раз подряд. Причём, наверное, вёрстка like-кнопки будет и через пару лет сильно кривиться в зависимости от вёрстки сайта, на котором она размещена. Догадаться разместить её в <body/> похоже слишком сложно. 

Одновременно с этим на половину сломалась подгрузка изображений vkontakte-ом при share-ах. Причина не ясна. Судя по документации, ему должно хватать og:image. Ограничений по нему не указано. Debug-страницы для просмотра ошибок, похоже, до сих пор нет. Поиск результатов не дал. Спасибо, vKontakte.