Zubashev Stepan's blog

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 :(

Landings

One more video (with my launches) is after the break.

Пост-заметка об 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. Да, она у всех включена по-умолчанию.