Примитивный скрипт на JavaScript, подсчитывающий кол-во повторений английских слов без учёта морфологии и пр. лингво-хитростей:

"use strict"; /* eslint-env es6 */

const fs = require('fs');

function calculate(source)
{
	const words = source
		.toLowerCase()
		.replace(/[^a-z0-9'’]+/gm, ' ')
		.split(/\s+/)
		.filter(s => s.length)
		.reduce((map, word) =>
		{
			if(!map.get(word))
				map.set(word, 0);
			map.set(word, map.get(word) + 1);
			return map;
		}, new Map());

	return Array.from(words)
		.sort((a, b) => a[1] < b[1] ? 1 : -1);
}

const [,, sourceF, destinationF ] = process.argv;
if(!fs.existsSync(sourceF))
	throw new Error('Couldn\'t find "' + sourceF + '" file');

const source = fs.readFileSync(sourceF).toString();
const words = calculate(source);
console.info('Found ' + words.length + ' words.');

const str = words
	.map(([word, count]) => `${word} = ${count}`)
	.join('\n');
fs.writeFileSync(destinationF, str);
console.info('Count-map\'s written into "' + destinationF + '" file');

Из простых, но действенных, решений можно фильтровать все слова:

1. с апострофами (Mike's, I'm, You're, Can't, Don't, You'll, etc)
2. отдельно стоящие числа (или вообще все слова с числами)

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

Как минимум:

• Актуальная версия 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', ''). И вот оно сломалось.