Пять встроенных API Node.js, которые заменяют npm-пакеты

Если вы всё ещё устанавливаете npm-пакеты для базовых HTTP-запросов, файловых операций или тестирования, вы добавляете ненужные зависимости в свои Node.js-проекты. Современный Node.js (v20+) включает мощные встроенные API, которые устраняют необходимость во многих популярных пакетах, уменьшая размер бандла, повышая безопасность и упрощая поддержку.

Давайте рассмотрим пять важных встроенных API Node.js, которые могут заменить npm-пакеты, которые вы, вероятно, используете прямо сейчас, с практическими примерами, показывающими, как именно выполнить переход.

1. Глобальный fetch() заменяет axios и node-fetch

Нативный fetch API, стабильный с Node.js 18, обрабатывает большинство HTTP-запросов без внешних зависимостей. Хотя пакеты вроде axios предлагают удобства, такие как перехватчики и автоматические повторы, fetch() покрывает большинство сценариев использования.

До (с axios):

const axios = require('axios');
const response = await axios.get('https://api.github.com/users/nodejs');
console.log(response.data);

После (нативный fetch):

const response = await fetch('https://api.github.com/users/nodejs');
const data = await response.json();
console.log(data);

Для таймаутов используйте AbortController:

const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);
const response = await fetch(url, { signal: controller.signal });

Когда оставить axios: Сложные цепочки перехватчиков, отслеживание прогресса или автоматические повторы запросов.

2. node:test Runner заменяет Jest и Mocha

Встроенный test runner (стабильный и рекомендуемый в Node.js 20+) предоставляет решение для тестирования без зависимостей, идеальное для библиотек и простых приложений.

До (с Jest):

// Requires jest installation and configuration
describe('Math operations', () => {
  test('adds numbers', () => {
    expect(2 + 2).toBe(4);
  });
});

После (нативный node:test):

import { test } from 'node:test';
import assert from 'node:assert';

test('adds numbers', () => {
  assert.strictEqual(2 + 2, 4);
});

Запустите тесты командой: node --test или node --test --watch для автоматического перезапуска.

Когда оставить Jest: Snapshot-тестирование, обширные утилиты для моков или необходимость в отчётах о покрытии кода.

3. Помощники файловой системы заменяют rimraf, mkdirp и glob

Современные методы fs обрабатывают рекурсивные операции и сопоставление с шаблонами нативно.

До (несколько пакетов):

const rimraf = require('rimraf');
const mkdirp = require('mkdirp');
const glob = require('glob');

await rimraf('dist');
await mkdirp('dist/assets');
const files = await glob('src/**/*.js');

После (нативный fs):

import { rm, mkdir } from 'node:fs/promises';
import { glob } from 'node:fs';

await rm('dist', { recursive: true, force: true });
await mkdir('dist/assets', { recursive: true });

// Note: glob() requires Node.js 22+
for await (const file of glob('src/**/*.js')) {
  console.log(file);
}

Эти нативные возможности Node.js устраняют три зависимости с идентичной функциональностью.

4. crypto.randomUUID() заменяет пакет uuid

Генерируйте криптографически безопасные UUID без пакета uuid (161 млн еженедельных загрузок).

До:

const { v4: uuidv4 } = require('uuid');
const id = uuidv4();

После:

import { randomUUID } from 'node:crypto';
const id = randomUUID();

Этот встроенный API генерирует UUID версии 4 по RFC-4122 с теми же гарантиями безопасности, что и пакет uuid.

Когда оставить uuid: Генерация UUID других версий (v1, v3, v5).

5. WebSocket-клиент заменяет пакет ws

Node.js включает глобальный WebSocket-клиент (стабильный в Node.js 22+). Он подходит для клиентского использования, но серверная поддержка WebSocket всё ещё требует пакетов вроде ws.

До (с ws):

const WebSocket = require('ws');
const ws = new WebSocket('wss://echo.websocket.org');
ws.on('open', () => ws.send('Hello'));

После (нативный WebSocket):

const ws = new WebSocket('wss://echo.websocket.org');
ws.onopen = () => ws.send('Hello');
ws.onmessage = (event) => console.log(event.data);

Когда оставить ws: Серверные реализации WebSocket или продакшен-использование до стабилизации API.

Выполнение перехода: практические соображения

Перед заменой npm-пакетов на нативные API учтите:

• Требования к версии Node.js: Убедитесь, что ваше продакшен-окружение работает на Node.js 20+ (в идеале 22 LTS)
• Паритет функций: Нативные API могут не иметь продвинутых функций (перехватчики axios, снапшоты Jest)
• Знакомство команды: Учитывайте кривую обучения для различных API

Начните с замены простых утилит, таких как randomUUID() и файловые операции. Они предлагают немедленные преимущества с минимальным риском. Для более сложных замен, таких как фреймворки для тестирования или HTTP-клиенты, оцените, соответствуют ли нативные функции вашим конкретным требованиям.

Заключение

Эти пять встроенных API Node.js демонстрируют, как платформа эволюционировала, чтобы снизить зависимость от внешних пакетов. Используя нативные fetch, node:test, современные методы fs, утилиты crypto и поддержку WebSocket, вы можете значительно уменьшить количество зависимостей вашего проекта, сохраняя — или даже улучшая — функциональность.

Ключ в том, чтобы знать, когда нативных API достаточно, а когда специализированные npm-пакеты всё ещё предоставляют ценность. Начинайте с малого, тщательно тестируйте и постепенно переходите на нативные решения там, где это имеет смысл для вашего случая использования.

Часто задаваемые вопросы

Могу ли я использовать эти встроенные API со старыми версиями Node.js?

Большинство функций требуют Node.js 18 или новее. fetch API требует v18+, node:test требует v20+, а glob требует v22+. Проверьте версию Node.js вашего продакшен-окружения перед миграцией с npm-пакетов.

Сломает ли удаление npm-пакетов мой существующий код?

Нет, если вы мигрируете аккуратно. Нативные API имеют другой синтаксис, чем npm-пакеты. Тщательно тестируйте в разработке, обновите свой код в соответствии с новыми паттернами API и рассмотрите возможность сохранения пакетов для продвинутых функций, которые нативные API не поддерживают.

Являются ли нативные API такими же производительными, как специализированные npm-пакеты?

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