Экосистема Angular изначально построена вокруг строго определённой цепочки сборки, в которой центральную роль играет Angular CLI и его внутренняя конфигурация на базе Webpack (в современных версиях — с переходом к более абстрактным сборочным слоям, но с сохранением Angular-specific пайплайна). Parcel, напротив, реализует модель «zero-configuration bundler», где анализ зависимостей и трансформация кода происходят автоматически без явного описания пайплайна.
Эта разница приводит к ключевому ограничению: Angular ожидает наличие специализированной сборочной инфраструктуры, тогда как Parcel ориентирован на универсальные JavaScript-проекты без framework-specific этапов компиляции.
Angular-компиляция включает несколько обязательных стадий:
@Component, @NgModule,
@Injectable)В Parcel отсутствует встроенный механизм понимания Angular-метаданных. Он работает на уровне файлов и модулей ECMAScript, но не интерпретирует семантику Angular-декораторов.
Особенно критичны следующие аспекты:
Ivy compilation (Angular 9+) Ivy генерирует фабрики
и инструкции на этапе сборки. Angular CLI выполняет эту трансформацию
через ngtsc, тогда как Parcel не имеет интеграции с Angular
compiler pipeline.
AOT (Ahead-of-Time) AOT требует предварительной компиляции шаблонов до запуска приложения. Parcel не управляет этим процессом, поскольку не реализует специализированный TypeScript transformer pipeline.
Angular активно использует TypeScript с включёнными экспериментальными декораторами и строгими настройками компилятора:
emitDecoratorMetadata: trueexperimentalDecorators: trueParcel использует esbuild или SWC (в
зависимости от версии), но их поддержка Angular-специфичных настроек
ограничена.
Ключевая проблема заключается в следующем:
Это разрывает цепочку Angular compiler.
Angular использует собственную систему маршрутизации и lazy loading модулей:
loadChildren с динамическими импортамиParcel поддерживает code splitting на уровне динамических
import(), однако Angular lazy loading требует:
Parcel не учитывает Angular Router как часть сборочного графа, поэтому структура чанков может расходиться с ожидаемой моделью Angular-приложения.
Angular CLI управляет сложной системой ассетов:
angular.json описывает assets, styles, scriptsParcel использует иной подход:
angular.jsonЭто создаёт расхождение в обработке:
templateUrl,
styleUrls)Angular DI система требует сохранения метаданных классов. Parcel активно применяет tree-shaking через статический анализ ES-модулей.
Конфликт возникает в следующих сценариях:
providedIn: 'root'Angular CLI защищает DI-граф от агрессивного tree-shaking, тогда как Parcel не обладает знанием Angular DI semantics.
Hot Module Replacement в Angular реализуется через Angular CLI Dev Server и интеграцию с zone.js.
Parcel предоставляет собственный HMR-механизм, основанный на замене модулей ES.
Различие проявляется в том, что Angular приложение:
Parcel HMR работает на уровне модулей и не управляет Angular change detection cycle, что приводит к потере состояния компонентов или неконсистентному обновлению дерева компонентов.
Angular поддерживает встроенные механизмы i18n:
Parcel не имеет интеграции с Angular i18n pipeline. Любые трансформации шаблонов выполняются без учёта Angular compiler extraction step.
Angular применяет ViewEncapsulation:
Parcel обрабатывает CSS как независимые модули, не учитывая Angular view encapsulation semantics. Это приводит к различиям:
_ngcontent-*)Angular CLI синхронизирует эти процессы через компилятор шаблонов, Parcel — нет.
Переход к standalone components (Angular 14+) частично снижает зависимость от NgModules, но не устраняет необходимость Angular compiler pipeline.
Даже при использовании standalone архитектуры остаются критичными:
Parcel по-прежнему остаётся вне этого пайплайна, так как не реализует Angular-specific трансформации AST.
Совокупность ограничений можно свести к нескольким фундаментальным несоответствиям:
Эти ограничения формируют архитектурный разрыв между универсальным bundler-подходом Parcel и специализированной компиляционной системой Angular.