Сборка приложения и сборка библиотеки решают принципиально разные задачи, что напрямую влияет на структуру выходных файлов, стратегию бандлинга и уровень оптимизации.
Приложение рассматривается как конечная точка исполнения. Оно запускается в браузере или Node.js и управляет собственным окружением. В этом случае сборщик стремится:
Библиотека, напротив, является переиспользуемым модулем, который будет встроен в другие проекты. Основная цель:
Эта разница определяет поведение Parcel при формировании итогового результата.
В приложении входная точка обычно одна — index.html или
index.js. Parcel строит граф зависимостей от этой точки и
оптимизирует всё дерево под единый результат.
В библиотеке входных точек может быть несколько:
src/index.js);src/utils.js,
src/components/*);Структура библиотеки ориентирована на экспорт модулей, а не на запуск.
Parcel в режиме библиотеки учитывает необходимость сохранить границы модулей, если это требуется форматом вывода (ESM/CJS), либо объединить их только частично.
Для приложений чаще используется один формат — оптимизированный бандл под конкретную среду.
Для библиотек критически важно поддерживать несколько форматов одновременно:
<script>.Parcel позволяет конфигурировать цели сборки через
package.json, где каждая цель определяет собственный формат
вывода:
{
"targets": {
"default": {
"distDir": "dist",
"source": "src/index.js",
"context": "browser",
"outputFormat": "esmodule"
},
"cjs": {
"outputFormat": "commonjs"
},
"umd": {
"outputFormat": "umd",
"global": "MyLibrary"
}
}
}Такой подход делает библиотеку мультиформатной, тогда как приложение обычно ограничивается одной целью.
Одно из ключевых различий — стратегия обработки зависимостей.
В приложении зависимости почти всегда встраиваются в бандл. Это уменьшает количество запросов и упрощает деплой.
В библиотеке часть зависимостей должна оставаться внешней:
react, vue, svelte — часто
объявляются как peerDependencies;Parcel в библиотечном режиме позволяет управлять этим через
externals-подобное поведение (через
package.json и конфигурацию targets). Итоговый бандл
сохраняет только код самой библиотеки, не дублируя окружение.
В приложениях Parcel может агрессивно оптимизировать весь граф:
В библиотеках оптимизация более осторожная.
Причина — необходимость сохранить:
Особенно важно поведение sideEffects в
package.json:
{
"sideEffects": false
}или частичное указание:
{
"sideEffects": ["./src/polyfills.js"]
}Для библиотек это критично, поскольку неправильная оптимизация может привести к удалению кода, который используется косвенно.
В приложениях Parcel активно применяет code splitting:
import() создают отдельные чанки;В библиотеках code splitting используется ограниченно. Причина — библиотека должна быть предсказуемой единицей поставки.
Типичные ограничения:
Исключение составляют библиотеки с плагинной архитектурой или крупные UI-kit системы.
Parcel v2 использует концепцию targets, которая заменяет классические конфиги сборки.
В приложении обычно один target:
context: browserengines: { "browsers": [...] }distDir: distВ библиотеке targets становятся многоуровневыми:
Каждый target может иметь:
Это позволяет одной командой сборки формировать полный набор артефактов библиотеки.
Для библиотек package.json играет роль контракта с
внешним миром.
Ключевые поля:
main — CommonJS entry;module — ESM entry;exports — современное описание публичного API;types — TypeScript декларации;files — список публикуемых артефактов.Пример:
{
"name": "my-lib",
"version": "1.0.0",
"main": "./dist/index.cjs",
"module": "./dist/index.js",
"types": "./dist/index.d.ts",
"exports": {
".": {
"import": "./dist/index.js",
"require": "./dist/index.cjs"
}
}
}В приложении подобная структура обычно отсутствует, поскольку конечный результат не предназначен для импорта другими проектами.
В приложении Parcel часто инлайнит или глобализирует ассеты:
В библиотеке поведение зависит от назначения:
Ключевое отличие — необходимость контролировать интеграцию с внешним приложением, а не просто доставить готовый UI.
В приложениях source maps часто включаются в полном объёме для упрощения диагностики.
В библиотеках подход более вариативен:
Причина — снижение веса пакета и защита внутренней структуры реализации.
Одной из частых проблем становится попытка собрать библиотеку по модели приложения.
Это приводит к следующим последствиям:
Другой распространённый сценарий — избыточное code splitting, при котором библиотека поставляется в виде множества чанков, не ожидаемых сборщиками внешних проектов.
Библиотечная сборка требует строгой стабилизации экспортов:
Parcel в этом контексте выступает как инструмент трансформации, но не определяет архитектуру — она задаётся структурой исходного кода и контрактом пакета.
В приложениях различие режимов влияет в первую очередь на производительность:
В библиотеках это различие дополнительно влияет на:
Production-сборка библиотеки фактически определяет внешний интерфейс, тогда как development используется только для разработки самой библиотеки.