Автообновление npm зависимостей

Многие до сих пор проверяют зависимости package.json вручную или через npm outdated.
Но есть инструмент, который сделает это удобнее и проще: npm-check-updates (ncu).

Установка:

npm install --global npm-check-updates

ncu          # показать обновления
ncu -u       # обновить package.json
npm install  # установить зависимости

Показать обновления до определенного уровня:

ncu --target patch
ncu --target minor
ncu --target latest

Показать обновления определенных пакетов:

ncu -f webpack  # только webpack
ncu -x webpack  # всё, кроме webpack

Проверка обновлений глобальных зависимостей:

ncu -g

Игнорирование пакетов:

// .ncurc
{
  "reject": ["webpack", "eslint", "@types/*"]
}

⚠️ Пока нет возможности ограничить пакеты только определенным интервалом версий.

npm-check-updates даёт полный контроль, гибкость и удобство в настройке, лучше подходит для автоматизации процесса.

#npm

Улучшение дефолтного поведения TypeScript

ts-reset — утилита, которая расширяет стандартную типизацию в TypeScript, устраняя устаревшие и нестрогие участки в базовых API.
Подключается на уровне проекта и повышает строгость типизации в ряде API.

Установка:

npm install --save-dev ts-reset

// reset.d.ts
import "@total-typescript/ts-reset";

Также возможно установить отдельные правила:

// reset.d.ts
import "@total-typescript/ts-reset/json-parse";
import "@total-typescript/ts-reset/fetch";

Основные изменения:

• JSON.parse, .json(), localStorage, sessionStorage теперь возвращают unknown, а не any
• .filter(Boolean) корректно удаляет falsy-значения
• .includes(), .indexOf(), Set.has(), Map.has() не требуют точного сравнения (чего и пытаемся добиться, вызывая их)
• Array.isArray() больше не считает any[] безопасным

⚠️ Не рекомендуется использовать в библиотеках, так как изменения глобальных типов могут повлиять на конечные проекты, в которые библиотека будет установлена.

Внутри существующих проектов подключение ts-reset, как правило, не вызывает проблем: типы становятся строже, но остаются совместимыми с корректным кодом.
Если после подключения появляются ошибки — скорее всего, это участки, где типизация и так была небезопасной.

#npm #typescript

Типизация querySelector

typed-query-selector — улучшение типизации методов querySelector и querySelectorAll с выводом типов на основе CSS-селекторов.

⚠️ Требуется TypeScript версии 4.1 или выше.

Установка:

npm install --save-dev typed-query-selector

// typed-query-selector.d.ts
import "typed-query-selector";

Результат:

document.querySelector("div#app"); // HTMLDivElement
document.querySelector("div#app > form#login"); // HTMLFormElement
document.querySelectorAll("span.badge"); // NodeListOf<HTMLSpanElement>
document.querySelector("button#submit"); // HTMLButtonElement

#npm #typescript

Очистка node_modules от устаревших полифилов

Даже если вы используете Current или LTS версию Node.js, многие популярные пакеты по-прежнему тянут за собой устаревшие полифилы — вплоть до Node.js 4.
Они часто попадают в проект как зависимости — например, eslint-plugin-import, eslint-plugin-jsx-a11y, eslint-plugin-react.
Это увеличивает размер node_modules, замедляет установку и даже выполнение кода.
Всё потому, что некоторые из этих полифилов используются вместо нативных API, даже если они уже доступны в среде выполнения, что снижает производительность, хотя в этом нет нужды.

nolyfill — это CLI-инструмент, который автоматически находит и заменяет устаревшие полифилы на безопасные заглушки.

⚠️ Он вам не подойдет, если ваш проект запускается на версии Node.js ниже 12.4.0 или вы разрабатываете под среду, которая не поддерживает ECMAScript2019.

Использование:

npx nolyfill // Найдёт полифилы в текущем проекте
npx nolyfill install // Заменит их на заглушки

Если вы часто меняете зависимости, чтобы не забывать запускать nolyfill — добавьте вызов в postinstall:

// package.json
{
  "scripts": {
    "postinstall": "npx nolyfill"
  }
}

Современный стек требует современных решений.
nolyfill — это простой способ освободить проект от наследия старых зависимостей и сделать шаг к современному, быстрому и чистому JavaScript.

#npm

Spellcheck для любого текста

Ошибки бывают не только в логике, но и в словах.
Особенно если проект мультиязычный или с большим количеством переменных, комментариев и документации.

cspell — это CLI-инструмент, который проверяет орфографию прямо в коде: в идентификаторах, строках, комментариях и текстовых ресурсах.
Работает быстро, легко настраивается и поддерживает словари для десятков языков.

Пример базовой настройки:

npm install --save-dev cspell @cspell/dict-ru_ru

// package.json
{
  "scripts": {
    "lint:cspell": "cspell **"
  }
}

// .cspell.json
{
  "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json",
  "version": "0.2",
  "language": "en,ru",
  "import": ["@cspell/dict-ru_ru/cspell-ext.json"]
}

Так получаем проверку орфографии русских и английских слов за один проход по проекту.

Выше представлена базовая конфигурация. Ознакомившись с документацией, вы сможете:
- подключать словари технических терминов, определенных фреймворков и библиотек
- добавлять собственные словари
- создавать отдельные настройки под каждый язык программирования
- тонко настраивать правила, используя маску для разрешения или запрета определенных слов

Если вы хотите поддерживать порядок не только в коде, но и в текстах — cspell поможет избежать опечаток и сэкономит время ревьюеров.

#linters #npm

Быстрая очистка node_modules

npkill — это CLI-утилита, которая ищет каталоги node_modules и позволяет удалять их одним нажатием клавиши.

Запуск:

npx npkill

По умолчанию утилита просканирует текущую папку и все вложенные каталоги на наличие node_modules.
Перемещаясь стрелками и нажимая Space, можно тут же удалить любую найденную папку с пакетами.

⚠️ npkill удаляет каталоги без подтверждения. Убедитесь, что у вас остались lock файлы, чтобы при необходимости быстро восстановить зависимости.

Периодическая очистка зависимостей в неактуальных или забытых проектах может освободить десятки гигабайт.
npkill позволит сделать это быстро и просто.

#npm

Поиск влитых git-веток и связанных задач

В крупном репозитории, где одновременно работают несколько разработчиков, может быть до 30 активных веток, часть из которых на паузе, часть в работе, а часть размечены в предстоящий релиз.
После каждого релиза такие ветки нужно удалять, делать это вручную — занятие сомнительное.
Чтобы не пропустить ветку или не удалить нужную, можно воспользоваться git-merged-branches.

git-merged-branches — это CLI-утилита, которая показывает ветки, влитые в основную (master или main).
Работает локально, проста в использовании, не имеет дочерних зависимостей и доступна также под коротким алиасом gmb.

Главная фича — возможность просматривать ссылки на задачи из трекера прямо в списке веток, если в названии используются идентификаторы задач, такие как JIRA-123, BUG-42 и т.п.

Использование
Установить глобально:

npm install --global git-merged-branches

Или запустить через npx:

npx git-merged-branches

Вызвав git-merged-branches, или алиас gmb, утилита определит базовую ветку (master или main) и выведет список веток, которые уже были в неё влиты:

$ gmb

Branches merged into 'master':
bugfix/fix-crash-on-start
feature/add-new-feature
hotfix/urgent-fix

Настройка идентификаторов задач
Если вы используете префиксы задач в названиях веток, например TOKEN-123_fix-layout — можно настроить автоматическое добавление ссылок на трекер задач.

// package.json
{
  "git-merged-branches": {
    "issueUrlFormat": "https://jira.my-company.com/browse/{{prefix}}{{id}}",
    "issueUrlPrefix": ["TOKEN-", "BUG-"]
  }
}

Что изменит вывод на такой:

TOKEN-123_fix-layout <https://jira.my-company.com/browse/TOKEN-123>
BUG-56_add-tests <https://jira.my-company.com/browse/BUG-56>

git-merged-branches — минималистичная, но полезная утилита, которая позволит быстро почистить ветки, заодно проверив их статус в трекере.

#npm

ESLint плагины: compat

С постоянным развитием стандарта ECMAScript и Web API вы наверняка сталкивались с ситуацией, когда хочется использовать новую возможность языка или API, но возникает вопрос — заработает ли это у пользователей. Возможно, вы даже добавляли полифиллы пару лет назад, но теперь уже не помните какие из них всё ещё нужны.

Чтобы писать код и не задумываться об этом, можно воспользоваться плагином eslint-plugin-compat — он автоматически проверит, поддерживаются ли используемые функции в целевых браузерах.

Установка

npm install --save-dev eslint-plugin-compat

// eslint.config.js
import compat from "eslint-plugin-compat";

export default [
  // ...
  compat.configs["flat/recommended"]
];

// package.json / .browserslistrc
{
  "browserslist": [
    "last 3 Chrome versions",
    "Firefox ESR"
  ]
}

Поддержка полифиллов
Если вы используете полифиллы, их нужно явно указать в настройках — плагин не будет реагировать на такие API:

// eslint.config.js
{
  "settings": {
    "polyfills": [
      "Promise",
      "WebAssembly.compile",
      "fetch",
      "Array.prototype.push"
    ]
  }
}

Итог
eslint-plugin-compat поможет предотвратить ситуацию, когда в прод попадает код, не работающий у части ваших пользователей. Если вы знаете, какие браузеры поддерживаете — подключите этот плагин, и ESLint сам предупредит, если появятся проблемы.

⚠️ Не забывайте обновлять caniuse зависимости, чтобы browserslist всегда соответствовал актуальным данным.

#linters #npm

ESLint плагины: markdownlint

Даже если вы не пишете код, то с Markdown всё равно сталкиваетесь — документация, README или статьи. Он проще HTML и надёжнее Word: незакрытый тег не сломает вёрстку, а добавление переноса не унесёт весь абзац в другое измерение. Но если тексты объемные, то в них быстро могут накапливаться стилистические ошибки и несогласованности: лишние пробелы, неправильные стили заголовков, нумерация списков и так далее. Это мелочи, но исправив их, текст станет гораздо проще для восприятия.

eslint-plugin-markdownlint помогает подсветить такие ошибки: он интегрирует проверку Markdown-файлов прямо в ESLint, используя правила markdownlint.

Установка

npm install --save-dev eslint-plugin-markdownlint

// eslint.config.js
import markdownlintPlugin from "eslint-plugin-markdownlint";
import markdownlintParser from "eslint-plugin-markdownlint/parser.js";

const markdownlintPluginConfig = {
  files: ["*.md", "*.mdx"],
  plugins: { markdownlint: markdownlintPlugin },
  languageOptions: { parser: markdownlintParser },
  rules: markdownlintPlugin.configs.recommended.rules
};

export default [
  // ...
  markdownlintPluginConfig
];

Возможности
- Плагин поддерживает проверку .mdx файлов.
- Использует ESLint инфраструктуру — не нужно ставить дополнительные библиотеки.
- Большинство правил поддерживают autofix через --fix.
- Можно адаптировать любые правила под свои нужды, либо отключить ненужные.

Что именно он проверяет?
Базовые правила покрывают самые частые ошибки и несоответствия:
- Заголовки: MD001, MD003, MD018, MD025 — стили, отступы, вложенность.
- Списки и блоки: MD004, MD005, MD007, MD030, MD032.
- Отступы, пробелы и переносы строк: MD009, MD010, MD012, MD047.
- Код и ссылки: MD014, MD040, MD042, MD052.
- Общие стилистические правила: MD026 (точка в заголовке), MD036 (курсив вместо заголовка), MD041 (H1 — первой строкой).
- Вёрстка таблиц и inline-html: MD033, MD055, MD058

Полный список правил.

Итог
Если в вашем проекте с Markdown уже используется ESLint — подключите этот плагин и пишите аккуратные тексты не отвлекаясь на стилистические правки.

#linters #npm

ESLint плагины: pinia

Хранилища (далее сторы) в Pinia — это основа архитектуры любого Vue-приложения. Но чем больше проект, тем сложнее следить за тем, чтобы все defineStore были реализованы одинаково, не было дублирующихся id, а свойства явно экспортировались.

eslint-plugin-pinia поможет автоматизировать эти проверки: после подключения в ESLint плагин найдет потенциальные ошибки, несогласованный стиль и архитектурные несоответствия в ваших stores.

Установка

npm install --save-dev eslint-plugin-pinia

// eslint.config.js
import piniaPlugin from "eslint-plugin-pinia";

export default [
  // ...
  piniaPlugin.configs["all-flat"]
];

Что проверяет?
Правила покрывают самые частые ошибки:
- never-export-initialized-store — запрещает экспортировать результат defineStore(), только саму функцию.
- no-duplicate-store-ids — проверка уникальности id у всех defineStore.
- no-return-global-properties — запрет возврата inject, useRouter, useRoute из стора напрямую.
- no-store-to-refs-in-store — storeToRefs() не должны использоваться внутри defineStore.
- prefer-single-store-per-file — один файл должен содержать один стор. Отключено по умолчанию
- prefer-use-store-naming-convention — названия сторов должны начинаться с use: useCartStore, useUserStore, и т.д. Отключено по умолчанию
- require-setup-store-properties-export — все свойства state в setup-сторе должны быть экспортированы.

Итог
Если вы используете Pinia — этот небольшой плагин поможет избежать многих архитектурных проблем ещё на этапе написания кода. Особенно пригодится в командной работе: сторы будут оформлены единообразно, код станет предсказуемым, а ревью — быстрее и проще.

#linters #npm #pinia