Поиск по метке: node

Put this content:

[Unit]
Description={name}

[Service]
Type=simple
User={user}
ExecStart=/usr/bin/node {full-path-to-script}.js

[Install]
WantedBy=multi-user.target

... somewhere as {name}.service, where:

• {name} is the name of the service
• {user} is the name of the user to run the script (optional)

... then:

• run: this sudo ln -s /{full_path}/{name}.service /lib/systemd/system/{name}.service 
• then this: sudo systemctl daemon-reload
• then this: sudo systemctl enable {name}.service
• and finally this: sudo systemctl start {name}

How does it work?

• It starts the service on boot (see WantedBy section).
• Using ExecStart command. Important: we specify the full path to node
• SystemD remembers the PID of the new process and considers the service is ongoing until the process is died.
• So any subsequent systemctrl start {name} won't do anything if the previous process is alive.
• This behavior is determined by Type=Simple

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

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

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

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

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

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

Добрался до тестирования серверной части (node). Встал вопрос: а как проще всего протестировать вещи, связанные с БД? Подумал о том, что должен быть для Sequelize какой-нибудь драйвер, который отрабатывает прямо в ОЗУ. Сразу не нашёл, но зато нашёл вариант с sqlite и storage=memory. Сработало. В купе с хаками для mocha в виде beforeEach и afterEach, получилось довольно удобно. Работает молниеносно, подключается тривиально. Единственное ― приходится тягать пакет с sqlite тоже. В моём случае это оказалось совершенно не критичным. 

{ dialect: 'sqlite', storage: ':memory:', }

Случайно наткнулся на то, что можно вынести command line parameters для консольного запуска mocha в отдельный файл test/mocha.opts. Но тут же наткнулся на грабли. Файл должен лежать именно в test/mocha.opts, а у меня директория тестов называлась tests, и этого хватило. Т.е. механизм поиска файла сильно уступает аналогичному для, скажем, .eslintrc или .gitignore. Сам формат файла простой, пример:

--require test/setup.js
--compilers js:babel-core/register

Теперь mocha можно запускать без параметров. Интересная выресовывается картинка, много разных вспомогательных файлов: mocha.opts, .babelrc, .eslintrc, .gitignore, webpack.config.js, README.md, package.json и пр. шушера. А ведь не так давно мне было привычно размещать исходники прямо в корневой директории проекта, теперь же нужно им отдельную директорию создавать.

• Во-первых чтобы они не утонули среди вспомогательных файлов
• Во-вторых т.к. всё равно нужно куда-то итоговую сборку собирать
• В третьих таким образом удобно избегать node_modules (к примеру для поиска по файлам проекта)

Сразу отмечу, что статья не претендует на истину. Это всего лишь мои заметки о том, как вообще можно написать и запустить простые тесты для React, т.к. тут оказалось много места где заблудиться\окопаться. Итак, начнём.

Babel

Раз React значит и JSX, а значит и babel. Но простой запуск mocha просто запускает nodejs, в котором никакого JSX нет (и наверное никогда не будет). Что делать? Поиск подсказывает, что нужно запускать mocha (далее речь идёт именно о mocha) с флагом --compilers js:babel-core/register. Что сие есть? Это флаг заставит mocha предварительно компилировать код используя babel-core/register, который грубо изнасилуетподменяет require() в nodejs, что позволяет ему предварительно изуродоскомпилировать кодовую базу в нормальный javascript. 

Import\Export и .babelrc

Ок, но как babel-ю подсказать, что использовать в качестве конфига? Точного внятного ответа пока дать не могу, но как минимум можно создать в корне json-файл с именем .babelrc, который будет содержать json-конфиг. Мне прокатило, но в более сложных ситуациях нужно будет искать вариант поделикатнее. Собственно, чтобы не дублировать конфиг, имеет смысл подключить его и в webpack.config.js. Сразу отмечу, что взять и распарсить .babelrc как json простым вызовом require() nodejs почему-то не смогла (видимо мешает отсутствие расширения .json), поэтому fs.readFileSync и JSON.parse вам в помощь. 

Полифилы, JSDom и прочая нецензурщина

nodeJS это nodeJS, а не браузер, а для ряда тестов потребуется имитация браузера. И похоже, что на данный момент изящных решений нет, т.к. кодовая база react-* грубо сверяется с глобальным наличием window & document. Мде. Помимо прочего всякие полифилы, вроде regenerator-а (ну или отключить транспайлинг async-await в генераторы ещё до этапа компиляции) нужны. 

Для решения вопроса с полифилами достаточно import 'babel-polyfill'. а вот с JSDom так просто не срастётся. Я воспользовался таким решением:

• import 'jsdom-global/register';
• принудительно зафиксировал jsdom на 8-й версии (а не 10-й)

Замечу, что жизненноважно подключать этот костыль с JSDom до подключения React, иначе груды неадекватных глупых ошибок без внятных описаний украсят вашу безмятежную жизнь. Суть в том, что в недрах разных react-либ window кешируется ещё на этапе подключения файлов. И в последствии какой-нибудь флаг вида canUseDom === false будет вам яростно мешаться.

Можно подключать эти либы в каждом тест-файле, но тогда вы столкнётесь с тем, что при запуске сразу пачки тестов, babel-polifil будет падать со словами "я уже подключён", jsdom тоже будет что-нибудь базлать. Разумная альтернатива вынести обе эти строки в некий setup.js, а потом его подключать флагом --require tests/setup.js.

Сами тесты

React поставляет в пакете react-dom ряд инструментов для тестирования. Но даже на официальной странице этих инструментов упоминается, что вам стоит воспользоваться некой либой под названием enzyme. Установка оказалась не совсем тривиальной, т.к. сильно зависит от версии вашего React-а. Очень внимательно прочитайте инструкции по установке. Заодно доставьте к нему что-нибудь вроде chai для удобства тестирования.

Отмечу, что enzyme предоставляет по сути 3 набора утилит для работы с вашими React компонентами. А именно shallow для быстрого и поверхностного рендеринга, render для работы уже с html, и mount для полноценной работы с DOM и life-cycle React-компонентов. В любых маломальски сложных ситуациях готовьтесь к танцам с бубнами. Например .simulate метод для вызова событий умеет только React-события, а повешанные через addEventListener уже нет. Готовьтесь к нефинормативным ошибкам, куда же без них. 

Примеры кода для тестов можно посмотреть здесь. По правде говоря я, на данный момент, не в восторге ни от самой либы, ни от её документации.