Сегодня вышел Node.js 14. На medium был опубликован пост с описанием основных изменений — "Node.js version 14 available now".

Node.js 14 переходит на текущую ветку поддержки "Current", вытесняя оттуда Node.js 13. По плану через 6 месяцев (октябрь 2020) 14-ая версия перейдёт в фазу LTS. Node.js 12 будет поддерживаться до апреля 2022 года, Node.js 10 — до апреля 2021 года.

В Node.js 14 стабилизирован Diagnostic Report. Это API позволяет получить много полезной информации для локализации утечек памяти, причин падений и проблем производительности. В канале было несколько постов про эту фичу, их можно почитать тут и тут.

В новой версии доступен экспериментальный Async Local Storage API (есть бэкпорт для Node.js 13.10). Благодаря ему в Node.js появляется готовый инструмент для сохранения данных на время жизни http-запросов и любых других асинхронных процессов.

Были сделаны мажорные исправления в Streams API для улучшения согласованности и устранения неоднозначности. Например, http.OutgoingMessage теперь подобен stream.Writable, а net.Socket ведёт себя точно также как stream.Duplex. Ещё одно заметное изменение — включение по умолчанию опции autoDestroy.

Появилась экспериментальная поддержка Web Assembly System Interface (WASI), цель которого упростить работу с нативными модулями в Node.js. Про WASI также был пост в канале ранее, его можно найти тут.

Движок V8 обновлён до v8.1. Новая версия приносит улучшения производительности и поддержку новых спецификаций: Optional Chaining, Nullish Coalescing, Intl.DisplayNames, Intl.DateTimeFormat ( calendar, numberingSystem ).

В Node.js 13 ECMAScript modules стали доступны без явной передачи флага --experimental-modules. В 14-ой версии сделан следующий значимый шаг — убрано предупреждение при использовании ESM ExperimentalWarning: The ESM module loader is experimental. Тем не менее формально ESM остаётся экспериментальной фичей, поэтому в будущем могут быть мажорные изменения.

#nodejs #release

https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e

25 апреля npm немного поштормило. Ошибка в пакете is-promise, привела к поломке трёх миллионов зависимых проектов. Форбс Линдсей — автор библиотеки — написал постмортем.

После добавления поддержки ESM новый файл index.mjs не был добавлен в секцию files в package.json. Также в секции exports идентификатор модуля был без префикса ./. Из-за опубликованного кода перестал работать require вида require('is-promise/index'), require('is-promise/index.js'), require('is-promise/package.json').

С момента публикации сломанной библиотеки до её полного фикса прошло четыре часа. Для предотвращения проблем в будущем был удалён .npmignore и добавлен прогон тестов для Node.js 12 и 14, также были добавлены тесты, использующие npm pack для проверки публикуемого API и настроена публикация пакетов из CI. Разработчики Node.js в свою очередь обновили документацию, уточнив, что package.exports должен явно включать в себя все необходимые точки входа.

#npm #postmortem #esm #nodejs

https://medium.com/@forbeslindesay/is-promise-post-mortem-cab807f18dcc

Матиас Бус написал статью про исправление проблем производительности в Node.js web-фреймворке Hapi — "Hapi: A Performance deep-dive".

Матиас рассказывает про полный цикл поиска и устранения проблем производительности. В самом начале он подготавливает бенчмарк с помощью библиотеки autocannon. Затем были найдены куски кода, которые инициировали вызовы кода нативных библиотек. На горячих участках кода интероп между JavaScript и нативным кодом вызывает падение производительности. Для решения этой проблемы функции, приводящие к вызову нативного кода, были обернуты в геттеры. Была изменена логика инициализации плагинов, чтобы не выполнялась лишняя работа на каждый запрос к серверу. С помощью инструмента Clinic.js была обнаружена проблема с async-функциями. На данный момент V8 не очень хорошо оптимизирует код с async/await, поэтому не рекомендуется использовать async-функции на горячих участках кода. После внесения всех исправлений производительность Hapi улучшилась на 30%.

Полезная статья. Рекомендую почитать всем, кто работает с Node.js

#nodejs #performance

https://www.nearform.com/blog/hapi-a-performance-deep-dive/

Микаэль Роджерс написал пост про организацию совместимости Node.js-модулей, использующих ESM, и require — "Native ESM in Node.js with require() fallbacks".

Последние версии Node.js поддерживают нативную модульную систему и позволяют импортировать CommonJS-модули внутри ESM-файлов. Но может возникнуть ситуация, когда нужно обеспечить импорт ESM-файлов в CommonJS. Node.js не поддерживает такое направление импорта. Для обхода этого ограничения можно использовать export maps в package.json. В нём каждому файлу сопоставляются соответствующие CommonJS- и ESM-версии:

"exports": {
  ".": {
    "import": "./index.js",
    "require": "./dist/index.cjs"
  },
  "./basics.js": {
    "import": "./basics.js",
    "require": "./dist/basics.cjs"
  },
  ...
}

Для автоматического создания cjs-файлов из esm-файлов Микаэль воспользовался Rollup и небольшим конфигом.

Статья будет полезна тем, кто хотел использовать в своих пакетах ESM, но не делал этого из-за отсутствия совместимости с CommonJS.

#nodejs #esm

https://dev.to/mikeal_2/native-esm-in-node-js-w-require-fallbacks-and-support-for-all-front-end-compilers-2ded

Андрей Мелихов опубликовал на хабре статью "Архитектура современных корпоративных Node.js-приложений".

Фронтенд-разработка в больших проектах давно вышла за границы работы с представлением. Фронтендеры должны поддерживать сервер-сайд рендеринг и жонглировать ответами от разных бэкендов. В статье рассказывается про подход с организацией логики уровня приложения с помощью BFF (Backend For Frontend). Разбираются плюсы и минусы нескольких подходов разделения приложения на слои. В качестве примера реализации используется фреймворк Nest, по ходу дела разбираются его ограничения.

Очень хорошая статья. Рекомендую почитать всем, кто хочет узнать больше про разработку серьёзных web-приложений на Node.js.

#architecture #nodejs

https://habr.com/ru/company/yandex/blog/514550/