Расширение конфигурации по умолчанию

Parcel использует конфигурацию с минимальным количеством ручных настроек, опираясь на автоматическое определение типа проекта и встроенные пресеты. При этом система проектирования архитектуры сборщика построена вокруг идеи расширяемого конвейера (pipeline), который можно модифицировать без переписывания базовой конфигурации.

Ключевой принцип — наследование и дополнение поведения по умолчанию, а не его полная замена. Это достигается через систему .parcelrc, а также через конфигурации зависимых инструментов (Babel, TypeScript, PostCSS) и целевые настройки package.json.

Конфигурационный файл .parcelrc

Основная точка расширения поведения Parcel — файл .parcelrc. Он определяет, какие плагины участвуют в сборке и как устроены этапы обработки модулей.

Базовая структура:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.svg": ["@parcel/transformer-svg"]
  },
  "resolvers": ["@parcel/resolver-default"],
  "packagers": {
    "*.js": "@parcel/packager-js"
  }
}

Ключевой элемент — extends

Поле extends определяет наследование конфигурации:

  • @parcel/config-default — стандартный набор трансформеров, резолверов и оптимизаторов
  • пользовательские пресеты
  • композиция нескольких конфигураций

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

Слои конфигурационного конвейера

Parcel разделяет сборку на независимые стадии:

  • Resolvers — поиск модулей
  • Transformers — преобразование файлов
  • Bundlers — формирование бандлов
  • Packagers — упаковка результата
  • Optimizers — постобработка выходных файлов
  • Reporters — вывод информации о сборке

Расширение конфигурации обычно затрагивает один или несколько слоёв.

Расширение transformers

Transformers — наиболее часто расширяемая часть пайплайна. Они отвечают за преобразование исходных файлов.

Пример добавления собственного трансформера:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.md": ["@parcel/transformer-markdown"]
  }
}

Если необходимо расширить существующую цепочку, важно учитывать порядок выполнения:

{
  "transformers": {
    "*.js": [
      "@parcel/transformer-babel",
      "@parcel/transformer-typescript"
    ]
  }
}

Parcel применяет трансформеры последовательно, где результат одного становится входом другого.

Расширение resolver-логики

Resolvers определяют, как Parcel находит модули при import.

Стандартный резолвер:

{
  "resolvers": ["@parcel/resolver-default"]
}

Добавление кастомного поведения:

{
  "resolvers": [
    "@parcel/resolver-alias",
    "@parcel/resolver-default"
  ]
}

Здесь важно расположение:

  • верхний резолвер имеет приоритет
  • fallback осуществляется через resolver-default

Часто используется для:

  • алиасов путей
  • поддержки монорепозиториев
  • нестандартных структур модулей

Packagers и управление выходным форматом

Packagers формируют итоговые файлы бандла.

Пример расширения:

{
  "packagers": {
    "*.css": "@parcel/packager-css",
    "*.js": "@parcel/packager-js"
  }
}

При необходимости можно заменить упаковку для определённых типов файлов, например для интеграции с нестандартными окружениями (Electron, Workers, embedded runtime).

Optimizers как точка постобработки

Optimizers применяются после сборки бандла и влияют на размер и структуру финального кода.

{
  "optimizers": {
    "*.js": ["@parcel/optimizer-terser"]
  }
}

Расширение этой части пайплайна используется для:

  • минификации
  • tree-shaking на уровне результата
  • специфической оптимизации изображений или стилей

Presets как способ группового расширения

Parcel поддерживает конфигурационные пресеты — готовые наборы настроек.

Пример:

{
  "extends": "@parcel/config-default"
}

Можно создать собственный preset:

{
  "extends": "@my-scope/parcel-config"
}

Такой подход позволяет централизовать правила сборки для нескольких проектов.

Наследование и конфликт конфигураций

При объединении конфигураций применяется стратегия:

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

Пример конфликтного сценария:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.js": ["custom-transformer"]
  }
}

Здесь стандартный JS-трансформер может быть полностью заменён, если не включить его явно:

{
  "transformers": {
    "*.js": [
      "@parcel/transformer-babel",
      "custom-transformer"
    ]
  }
}

Расширение через package.json targets

Parcel позволяет дополнять конфигурацию через секцию targets в package.json.

{
  "targets": {
    "default": {
      "engines": {
        "browsers": ["last 2 versions"]
      },
      "outputFormat": "esmodule"
    }
  }
}

Основные параметры:

  • engines — целевая среда
  • outputFormat — формат сборки
  • distDir — выходная директория
  • sourceMap — управление картами исходников

Эта часть конфигурации не заменяет .parcelrc, а дополняет её на уровне проекта.

Интеграция с Babel и расширение трансформации JavaScript

Parcel автоматически использует Babel при необходимости, но его поведение можно расширять через babel.config.json.

{
  "presets": ["@babel/preset-env"],
  "plugins": ["@babel/plugin-proposal-class-properties"]
}

Parcel не требует ручной привязки Babel, но при наличии конфигурации он:

  • подхватывает её автоматически
  • интегрирует в pipeline трансформеров
  • сохраняет порядок выполнения через @parcel/transformer-babel

Расширение TypeScript обработки

TypeScript поддерживается через встроенный трансформер, но поведение контролируется tsconfig.json.

{
  "compilerOptions": {
    "strict": true,
    "module": "ESNext",
    "jsx": "react-jsx"
  }
}

Parcel использует TS не как компилятор, а как часть трансформационного слоя, что позволяет:

  • сохранять быстрый incremental build
  • комбинировать TS с Babel
  • расширять поведение без отключения стандартной цепочки

Расширение PostCSS pipeline

CSS-обработка расширяется через postcss.config.js:

module.exports = {
  plugins: [
    require("autoprefixer"),
    require("postcss-nested")
  ]
};

Parcel автоматически обнаруживает конфигурацию и внедряет её в pipeline CSS трансформаций.

Механизм частичного переопределения

Parcel не требует полного отказа от стандартного поведения. Расширение строится на принципе:

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

Пример гибридной конфигурации:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.css": [
      "@parcel/transformer-postcss",
      "custom-css-transformer"
    ]
  },
  "optimizers": {
    "*.css": [
      "@parcel/optimizer-cssnano"
    ]
  }
}

Композиция конфигураций в монорепозиториях

В монорепозиториях часто используется многоуровневое расширение:

{
  "extends": [
    "@company/parcel-config-base",
    "@company/parcel-config-react"
  ]
}

Такой подход позволяет:

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

Поведение при отсутствии конфигурации

Если .parcelrc отсутствует, Parcel использует:

  • встроенный @parcel/config-default
  • автоопределение типов файлов
  • стандартные трансформеры и резолверы

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

Приоритеты и порядок применения расширений

При обработке конфигурации Parcel учитывает:

  1. порядок extends
  2. локальные переопределения
  3. порядок массивов плагинов внутри ключей
  4. встроенные дефолты как fallback

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

Оглавление