This article is a small guide about how to configure an enviroment for babel-plugin-module-resolver. This plugin allows you use custom prefixes for import/export declarations in JS files. E.g. import A from 'com/A'  can be treated as import A from ../../components/A.

• At first you should install the package npm i -D babel-plugin-module-resolver. 
• Then add your map-config to your .babelrc file into the plugins section. E.g.:

plugins:
[
  // ...
  [
    "babel-plugin-module-resolver",
    {
        "alias": {
           "^com(.+)": "./src/com/\\1"
        }
    }
  ],
  // ...
]

• Then install npm i -D eslint-import-resolver-babel-module package for ESLint. It allows ESLint to check your rewrited imports, It assumes that you already use eslint-plugin-import package. If you don't I recommend you to start using it. This package checks your import/export declarations, it's very convinient.
• Then change in your .eslint file:

{
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": { "jsx": true }
  },
  "settings": {
    "import/resolver": { "babel-module": {} }
  },
  "plugins": [
    // ...
    "import"
  ],
  // ...
}

• You also need to install babel-eslint if you didn't do it yet. And move its declaration from parseOptions to the root of the .eslintrc.
• babel-module part in .babelrc section is just {}, it's okay.
• Install ESLint plugin in vsCode
• Probably you'll need to write in your .vcode/settings.json something like next lines. They force vscode to change CWD (current directory) in the deamon of eslint plugin:

"eslint.workingDirectories": [
	{
		"directory": "./client",
		"changeProcessCWD": true
	}
],

• If you use path-intellisense plugin, you should consider configurate your mapping in .vscode/settings.json too. 
• If you have any troubles, something doesn't work properly or doesn't work at all: Use force, Luke. Set vscode setting "eslint.trace.server": "verbose" and debug, debug, debug. I've spent on it several hours :(

Пост-заметка об ndb. Всем кто пишет для nodejs периодически приходится отлаживать своё приложение. Да даже тем, кто использует mocha или webpack бывает нет-нет да удобнее отладить по-человечески проблему, нежели тыкать повсюду console.log-и. NodeJS издавна предоставляет нам для этого браузерный инструмент.

Работает оно так:

• мы запускаем наше приложение из консоли с нужным флагом
• NodeJS в консоли нам сообщает ссылку с нужным портом
• Которую мы открываем в браузере и видим перед собой копию chrome-dev-tools-ов.

Если надо перезагрузить приложение ― повторяем всё с нуля. С одной стороны сами инструменты весьма удобные. С другой стороны вся эта мышиная возня с портами и перезапусками очень неудобна.

И тут на помощь к нам приходит ndb. Просто перед командой запуска приложения добавляем ndb. Dev-tools-ы открываются прямо в своём отдельном окне. Перезагрузить приложение можно нажав ctrl+R. Все breakpoint-ы и прочая муть при этом сохраняется. 

Выглядит это всё примерно так:

С приходоим ES7 в JS пришли import-ы и export-ы. Жить стало веселее, и... сложнее. Появилось много заморочек и вообще новых проблем. Одна из таких проблем выглядит так: `import some from ../../../../../some`. Знакомая ситуация?

Обычно её в случае webpack-а решают при помощи модуля module-resolver. Он позволяет в .babelrc (или где вы держите конфигурацию) указывать регулярные выражения для автозамены, а также добавляет поддержку root-записей. Скажем с ним можно указать `import actions from '@actions/header', где `@actions` будет алиасом к какому-нибудь пути в вашем проекте. 

Дальше встаёт вопрос инструментов. А как на это должен реагировать редактор? Как он узнает, что теперь пути в import-ах устроены хитрее. Что делать с линтингом? К счастью, для eslint есть такой плагин:  eslint-plugin-import. С редакторами ситуация может быть сложнее.

Хорошо, а что делать с SCSS\Sass? Нормальных рабочих решений с наскоку мне найти не удалось. Но как оказалось, всё можно решить относительно просто. В настройках webpack для sass-loader-а можно указать настройки. Они будут переданы как есть в пакет node-sass. А вот он, оказывается, достаточно гибкий. Если там указать метод importer, то можно навязать свою логику обработки @import-ов. Пример:

{
	loader: 'sass-loader',
	options:
	{
		sourceMap: true,
		url: false,
		importer: url => (
		{
			file: url
				.replace(...)
				.replace(...)
				.replace(...),
		}),
	},
}

Либо даже выцепить ваши настройки прямо из настроек в .babelrc.

В который раз наткнулся на странную вещь. Телефон издаёт странный нестандартный непривычный звук. Подхожу - смотрю - реклама казино в google-календаре. В этот раз решил разобраться, как так. Стал рыться-копаться. Нет, таких записей в календаре у меня нет. Нет - к календарю ни у какого приложения доступа нет. WTF?

Разгадка - недоработка Gmail. Оказывается что если сформировать письмо правильным образом, то "умный" Google автоматически формирует в календаре Event под это письмо. И часть писем успевают сформировать такие спам-уведомления из календаря ещё до того момента, пока Google не определяет, что это спам и event-ы с письмами сносит. Однако диалог "пойду-не-пойду на мероприятие" на мобильнике при этом не тухнет. 

Лечится принудительным отключением в настройках Google Calendar опции: Automatically add events from Gmail to my calendar. Да, она у всех включена по-умолчанию.

Возникла необходимость внедрять готовый SPA в другой проект на страницу. Проект сразу писался под это дело, но всё равно возник ряд проблем, которые нужно было решать. Напишу про 2 из них сюда как шпаргалку.

webpack & dynamic import

Что если ваш проект использует динамический импорт? Например System.import. В этом случае webpack сделает для подгружаемых файлов отдельный chunk. И грузить он его будет исходя из publicPath в настройках webpack. Но ведь embedded решения могут быть внедрены по любому пути. Как быть? Всё просто, пишем в точке входа что-нибудь типа: __webpack_public_path__ = window.myPredefinedPath и дело в шляпе. Магия. До загрузки приложения нужно определить этот window.myPredefinedPath, webpack его увидит и будет использовать. Сразу отмечу, что надо писать как есть, не window.__webpack...=, а как-будто эта переменная уже определена в коде. Если на неё ругается eslint не беда, пишем: // eslint-disable-line и он более не ругается.

webpack css & url

Возникла проблема с тем, что в стилях указаны пути к шрифтам так, что webpack их найти не может (отдельная тема почему так). Да и не должен, него его это забота. Однако он пытается от-revolve-ить все пути, что находит в css. Лечится установкой url: false в cssLoader-е. После этой настройки пути отдаются как есть без каких-либо проверок.