Як виправити npm ERR! ERESOLVE could not resolve?
#npm

При встановленні залежностей можна часто побачити помилку:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Відновлення залежностей не завжди варіант. Тому до Node.js 16.14 рекомендований спосіб був прописати legacy-peer-deps=true у .npmrc проекту або використовувати yarn resolutions. У Node.js 16.14 йде npm 8.3. Цей апдейт додав overrides, аналог yarn resolutions. Приклад використання в package.json для одного проекту React:
"dependencies": {
"react": "^18.1.0",
"react-dom": "^18.1.0",
"react-json-view": "^1.21.3"
},
"overrides": {
"react-json-view": {
"react": "18.1.0",
"react-dom": "18.1.0"
}
}

Рецепти на тему:
– Що таке .npmrc і чому його варто додати?
– Як виправити код у node_modules?
– Тонкощі роботи з npm scripts

Коли використовувати npm ci?
#npm

Нагадаю npm ci або npm clean-install виконуватиме такі дії:
1. Видалить node_modules.
2. Встановити всі залежності з package-lock.json
На відміну від npm install, npm ci ніколи не змінюватиме ваш package-lock.json та викине помилку, якщо треба його змінити. Тому npm ci гарантую повторяємось.

В CI використовуйте npm ci та кешування node_modules або npm cache директорії (команда npm config get cache покаже де вона).

В Dockerfile використовуйте npm ci. Його слід роботи після копіювання package.json та package-lock.json але копіювання до js/ts файлів. Це треба для Docker layer caching.

При локальній розробці використовувати npm ci не принципово.

Чому потрібно використовувати scope у іменах пакетів?
#npm

Вчора я робив ревю Workshop: Integration testing of back-end applications і вкотре дав рекомендацію use naming with scope. Нагадаю, що ім'я може мати scope. Приклад: @nestjs/common.

Ось мої аргументи використовувати scope у всіх ваших пакетах:
1️⃣ вибір вільного та зрозумілого імені значно простіше. Приклад @<project_name>/eslint-config
2️⃣ на рівні коду очевидно які пакети внутрішні.
3️⃣ легко використовувати для потрібного scope окремий npm репозиторій. Детальніше Associating a scope with a registry

Але головний аргумент під час ревю воркшопу був не технічного плану. Порада була: Думай про Open Source як про майбутній бізнес. Колись проєкт може продавати підписку на частину пакетів і scope буде обов'язковий для цього. Приклад https://marmelab.com/ra-enterprise/

Що таке npm alias?
#npm
npm alias дозволяє встановити інший пакет, але не змінювати звернення до коду. Для цього використовується такий формат <alias>@npm:<name>. Приклади:
npm i @nestjsx/crud@npm:@rewiko/crud
npm i react@npm:@preact/compat react-dom@npm:@preact/compat

Ось посилання на документацію та ще нагадаю про patch-package

Що таке glob шаблони (або globbing)?
#cli #npm

JavaScript розробники нерідко роблять помилку у glob шаблонах. Ми їх використовуємо, щоб задати маску для файлів. Приклад:
eslint --fix 'src/*.js'.

Ці glob шаблони (або globbing) йдуть з Unix та нагадують RegExp. У JavaScript екосистемі є пакет minimatch який конвертую glob шаблон у RegExp. Звичайно ж, є і пакет glob від того самого автора, який є обгорткой до minimatch. Тому зустрічається термін minimatch syntax (приклад у eslint). Але правильний термін – glob/globbing.

Покажу, як виглядає типова помилка у використанні:
prettier --write 'src/*.js'
Очікування: будуть переформатовані всі файли у src.
Реальність: будуть переформатовані лише файли на першому рівні вкладеності.

Треба мати на увазі, що */?/etc працюють лише у path segments, тобто у іменах файлів/директорії. Для рекурсивного пошуку необхідно використовувати **. Тому правильна команда:
prettier --write 'src/**/*.js'

👉 Інструмент для перевірки/тренування тут.

Як використовувати npm ls?
#npm

Команда npm ls виводить версії пакетів та їх залежності. Формат виведення деревоподібний. Причому дерево будуватиметься на основі логічних зв'язків, а не фізичного розташування пакетів у node_modules. Глибина дерева визначається параметром depth.

Приклади використання:
👉 npm ls – покаже лише безпосередні залежності.
👉 npm ls --all – покаже лише всі залежності на будь-якому рівні.
👉 npm ls -g – покаже список глобально встановлених пакетів.
👉 npm ls axios – покаже дерево для пакету axios. Має зрозуміліший вигляд, ніж npm explain.

Шкідливі поради про залежності
#npm

⚠️ npm install займає багато часу, тому зберігайте node_modules в git.
⚠️ Для зміни залежностей редагуйте package.json. Так, у вас більше буде у виборі версії. Її краще вказувати * або latest
⚠️ Додайте до .gitignore package-lock.json/yarn.lock, це зменшить кількість git конфліктів.
⚠️ Економте місце за рахунок глобальної встановлення популярних залежностей: npm install -g lodash babel typescript
⚠️ Якщо ви перестали використовувати залежність, то не видаляйте її з package.json. Можливо вона десь ще використовується.
⚠️ Ігноруйте повідомлення під час npm install. Усі ці deprecated warnings і npm audit report це лише зайва витрата часу.
⚠️ Не використовуйте devDependencies/optionalDependencies – вони так само, як і NODE_ENV, застаріли.

TDD це не догма, а процес розробки. А який у вас процес?
#npm

Щоразу, коли я роблю аудит і бачу у package.json:
"test": "echo 'not implemented yet'"
я запитую одне й те саме питання, а чому у вас існує саме такий test скрипт? Не залежно від відповіді наступне питання завжди одне й те саме, яке винесене в заголовок. Подальше обговорення у 95% випадків показує, що в цьому конкретно репозиторії на тести немає часу/необхідності. А та ще за CI/CD відповідає інша команда, яка не знає про прапор --if-present.

Будь-який неоголошений скрипт із цим прапором не буде провалений. Тому, якщо ви виконуєте функцію техлід або DevOps інженера на проекті, то використовуйте де необхідно npm run test --if-present.

Ще нагадаю, що не кожен проект потребує юніт тестів, що лежать в основі TDD. Але кожен проект вимагає здорового глузду та знання використовуваних інструментів. Тож перечитайте документацію npm, node та вашого фреймворку.

У багатьох інструментів є не лише логотип, але й маскот, тобто талісман-тварина. Наприклад, маскотом докера є синій кит з контейнерами.

А ви знаєте, що маскотом #npm є вомбат? Proof
На ілюстраціях він часто грає з кубиками npm пакетів.

Ввечері п'ятниці я задаюся питанням, чи знав дизайнер, який придумав цього маскота?.. а чи знав той, хто затвердив цю айдентику?.. Чи знали вони, що кишечник вомбата влаштований таким чином, що він какає кубиками? Proof

Рецепт про те, як я оновлюю кубики вже наступного тижня. Всім гарних вихідних.

Як оновлювати залежність?
#npm

<offtop>Я переписував текст про оновлення вомбатових кубиків чотири рази, щоб це був рецепт для каналу, а не доповідь на конференцію.</offtop>

Особисто для мене найскладніша відповідальність тех.ліду – це стежити за актуальністю тех.стека. Занадто швидко прогресує екосистема JavaScript + DevOps + CloudNative. Однак у рамках тематики канали ми сьогодні говоритимемо лише про оновлення npm пакетів.

Почнемо з базових речей:
1️⃣ <offtop>Якщо у канал з'явиться інстаграм, то першою картинкою це буде блок-схема про вибір типу залежності для вашого пакета. </offtop> dependencies це то, що потрібно під час run-time або побудови проекту. Все інше, що необхідно під час тестування або локальної розробки це devDependencies (тести, літнги, тощо).
2️⃣ Автори пакетів з 0.X версією мають право ламати зворотну сумісність із кожним мінорним релізом. Конкретний приклад до жовтня 2022 року, коли вийшла 1.0 версія, автори axios мали повне моральне право ламати зворотну сумісність.
3️⃣ Треба використовуємо package-lock.json, щоб зберегти все дерево залежностей. Цей файл є частиною git-репозиторію, як composer.lock у php або .terraform.lock.hcl у DevOps.
4️⃣ Ви використовуєте актуальну версію вашого менеджера пакетів. Я волію слідувати мейнстріму, тому у нас npm@9 з третьою версією lockfileVersion. Якщо у вас не третя, то виправляється за допомогою npm i --lockfile-version 3 --package-lock-only. Якщо у вас не npm, то у вас чи вашого тех.ліда має бути чітка відповідь чому саме так.
5️⃣ необхідно видаляти залежності, що не використовуються.

Перейдемо як саме оновлювати залежності:
1️⃣ Правильно, тобто ви змінюєте залежності за допомогою команди npm install <packageName> або npm update <packageName>, а не за допомогою зміни package.json чи npm update. Поясню, змінювати файли через редактор, замість використання менеджера пакетів – це розсинхронізувати package.json та package-lock.json. npm update без імені пакета оновлює все, тобто це некеровано, отже неправильно.
2️⃣ Свідомо, тобто ви знаєте що саме змінилося у ваших залежностях. Для цього необхідно читати реліз ноутс. Мені в цьому допомагає njt. Приклад, njt axios r
3️⃣ Регулярно, тобто перевіряти наявність нових версій за допомогою npm outdated. На моїх проектах оновлення залежностей це один із аджайл ритуалів після релізу.

На завершення, нагадаю, що ваш додаток це не лише код, написаний вашою командою, а й конкретні версії бібліотек, які використовуються вашим кодом. Тому ставтеся до їхнього вибору (і оновленню) з відповідальністю!