Бандлинг для Lambda и serverless-функций

В serverless-экосистемах основная единица деплоя — функция, выполняемая в изолированной среде (AWS Lambda, Google Cloud Functions, Azure Functions). Ограничения на размер архива, время холодного старта, файловую систему и доступные runtime-библиотеки формируют специфические требования к процессу сборки. Parcel используется как инструмент, способный автоматизировать бандлинг кода и зависимостей в единый оптимизированный артефакт.

Parcel выполняет анализ графа зависимостей, объединяет модули, проводит трансформации (Babel, TypeScript, PostCSS), а затем формирует финальный бандл, пригодный для исполнения в Node.js-окружении Lambda.

Особенности serverless-окружения, влияющие на сборку

Serverless-функции отличаются от традиционных серверных приложений рядом ограничений:

  • ограничение размера деплоя (например, 50–250 MB в зависимости от платформы)
  • холодный старт, зависящий от количества загружаемого кода
  • ограниченный доступ к файловой системе (read-only /var/task)
  • отсутствие долгоживущих процессов
  • необходимость минимизации зависимостей

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

Базовая модель сборки Parcel для Lambda

Parcel строит граф зависимостей начиная с entry-point файла функции, например:

// handler.js
export async function handler(event) {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "OK" })
  };
}

Parcel анализирует импортируемые модули, объединяет их и формирует единый bundle:

parcel build handler.js --target node --dist-dir dist

Ключевой аспект — выбор target, определяющий поведение трансформаций и формат вывода.

Конфигурация target для Node.js

Для serverless-кода используется Node.js target, который обеспечивает совместимость с Lambda runtime:

{
  "targets": {
    "lambda": {
      "engines": {
        "node": ">=18"
      },
      "context": "node",
      "outputFormat": "commonjs",
      "includeNodeModules": false
    }
  }
}

Параметр includeNodeModules: false означает исключение node_modules из бандла. Это критично для:

  • уменьшения размера архива
  • ускорения холодного старта
  • использования нативных зависимостей Lambda runtime

Стратегии включения зависимостей

Parcel поддерживает несколько подходов к работе с зависимостями:

Полное бандлирование

Все зависимости включаются в итоговый файл.

Преимущества:

  • единый артефакт
  • отсутствие внешних зависимостей

Недостатки:

  • рост размера bundle
  • потенциальные проблемы с нативными модулями

Частичное бандлирование

Код приложения объединяется, а node_modules остаются внешними:

{
  "targets": {
    "lambda": {
      "includeNodeModules": false
    }
  }
}

Такой подход характерен для Lambda, где зависимости загружаются отдельно.

External dependencies

В некоторых сценариях часть пакетов помечается как внешняя:

{
  "targets": {
    "lambda": {
      "externals": ["aws-sdk", "sharp"]
    }
  }
}

Это особенно важно для AWS SDK, который часто уже присутствует в runtime.

Оптимизация размера бандла

Parcel выполняет несколько стадий оптимизации:

  • tree-shaking (удаление неиспользуемого кода)
  • minification
  • scope hoisting
  • dead-code elimination

В serverless-контексте tree-shaking приобретает критическое значение, так как даже небольшое сокращение влияет на cold start latency.

Работа с TypeScript в serverless-функциях

Parcel поддерживает TypeScript без дополнительной конфигурации:

export const handler = async (event: any) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ ok: true })
  };
};

В процессе сборки происходит:

  • удаление типов
  • транспиляция в JavaScript
  • объединение модулей в dependency graph

Type checking при этом может выполняться отдельно через tsc --noEmit.

Асинхронные импорты и code splitting

Dynamic imports позволяют разделять функциональность:

export const handler = async (event) => {
  const module = await import("./heavy-module.js");
  return module.process(event);
};

Parcel интерпретирует такие конструкции как точки разделения чанков. Однако в serverless-среде code splitting часто ограничен:

  • дополнительные чанки увеличивают число файлов в деплое
  • Lambda требует корректной структуры архива
  • latency загрузки может увеличиваться

Поэтому dynamic import применяется точечно, в основном для тяжёлых вспомогательных модулей.

Подготовка артефакта для AWS Lambda

После сборки Parcel формируется структура:

dist/
  handler.js
  handler.js.map

Дальнейшая упаковка:

cd dist
zip -r function.zip .

Этот архив загружается в Lambda как deployment package.

Интеграция с AWS SDK и встроенными библиотеками

В serverless-окружении часто используется AWS SDK, уже доступный в runtime. Его включение в бандл увеличивает размер без необходимости.

Конфигурация исключения:

{
  "targets": {
    "lambda": {
      "externals": ["aws-sdk"]
    }
  }
}

Это позволяет использовать встроенную версию SDK.

Работа с нативными модулями

Некоторые зависимости содержат native bindings (например, bcrypt, sharp). Parcel не всегда может корректно их встроить в единый bundle.

Типичная стратегия:

  • исключение из бандла
  • установка через npm install --platform=linux --arch=x64
  • включение в zip-архив вместе с bundle

Переменные окружения и конфигурация

Serverless-функции активно используют environment variables:

const region = process.env.AWS_REGION;
const table = process.env.TABLE_NAME;

Parcel не встраивает значения переменных автоматически, но позволяет использовать .env при сборке:

parcel build handler.js --env production

Дополнительно применяется dotenv на уровне рантайма:

import "dotenv/config";

Монорепозитории и serverless

В монорепозиториях Parcel анализирует зависимости между пакетами:

/packages
  /api
  /shared
  /core

Serverless-функция может импортировать внутренние пакеты:

import { validate } from "@shared/validator";

Parcel строит единый dependency graph, что позволяет избежать ручной сборки каждого пакета.

Логика cold start и влияние бандлинга

Cold start в Lambda зависит от:

  • размера zip-архива
  • количества модулей
  • времени инициализации runtime

Parcel влияет на все три параметра через:

  • объединение модулей
  • удаление неиспользуемого кода
  • оптимизацию структуры зависимостей

Уменьшение количества файлов внутри bundle часто оказывает большее влияние, чем микрооптимизации кода.

Деплой через CI/CD

Типичный pipeline:

  1. установка зависимостей
  2. сборка Parcel
  3. упаковка zip
  4. деплой в Lambda
npm ci
parcel build handler.js --dist-dir dist
cd dist && zip -r function.zip .
aws lambda update-function-code \
  --function-name my-function \
  --zip-file fileb://function.zip

Обработка нескольких функций в одном проекте

Parcel поддерживает multi-entry сборку:

/functions
  getUser.js
  createUser.js
  deleteUser.js

Конфигурация:

{
  "targets": {
    "lambda": {
      "source": "functions/*.js",
      "distDir": "dist"
    }
  }
}

Каждая функция получает отдельный bundle, что соответствует модели serverless-деплоя.

Сравнение подходов к сборке

В serverless-сценариях Parcel часто конкурирует с другими bundler-инструментами, однако его модель отличается:

  • автоматический dependency graph без ручной конфигурации
  • встроенные трансформеры
  • минимальная конфигурация
  • оптимизация под production без дополнительных плагинов

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

Оглавление