Как минимум:

• Актуальная версия RHL в какой-то глубокой бете. Некоторые инструменты, такие как onsen monaca, в итоге, прибиты ногами к конкретной версии (иначе оно попросту не работает). Даже готовые пресеты для webpack-а завязаны на конкретные версии. Обратной совместимостью там и не пахнет. Даже сообщений внятных о том, что изменилось в stack trace-ах не ждите. 
• Webpack server довольно хитро устроен внутри, поэтому такую связку очень сложно дебажить. Попробуйте ради интереса убрать [HMR] и [WDS] сообщения. В настройках плагинов такой опции нет. Попытка вырезать их из кода руками заставит вас детально разобраться в работе этого сервера. Ну или забить. Я забил :)
• Если ошибка произошла до первого успешного render-а, то stack trace показывает погоду на Марсе. Настоящая ошибка теряется в дебрях обёрток для ошибок.
• Если в Chrome Developer Tools для webpack's sourceMap-ов есть какая-то кривоватая, но поддержка, то в Firefox инструментах там просто хаос. Про stack trace-ы вообще молчу. Там просто ссылка строку в bundle.js. 
• React Hot Loader по понятным причинам не перегружает обновления методов, которые были за-bind-ны в contructor-е компонента сами на себя. В итоге приходится перегружаться почти по любому поводу.
• Любые не тривиальные случаи приводят к необходимости обновить страницу.

Сложилось стойкое впечатление, что 3-ая версия React Hot Loader-а всё ещё слишком сырая, чтобы ей можно было пользоваться за пределами задач вёрстки. Но я бы не стал даже в их пределах. Этот инструмент оборачивает всё своими proxy-методами, чем сильно портит жизнь.

Поддержка sourceMap-ов тоже пока оставляет желать лучшего. Слишком часто при debug-инге проваливаешься невесть куда, не можешь поставить breakpoint, а то и вовсе наблюдаешь какие-то аномалии. Поддержка stacktrace-ов тоже пока далека от идеала. 

Всё больше склоняюсь к разработке с ссылками на настоящие ресурсы, благо поддержка es6 в браузерах очень радует. Но вот JSX, я полагаю, нам в нативном виде в них не видать никогда. Так что вопрос, "а может к чёрту его этот JSX?" для меня лично достаточно актуален :) 

Небольшая заметка о том, как подключить в 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', ''). И вот оно сломалось. 

Чемпионаты Казахстана и России по дельтапланеризму 2016 в г. Алматы. 

подробности…