Архитектура

Один пакет, гранулярный подпутями, а не подпакетами, плюс спутники для всего тяжёлого. Страница объясняет, почему граница проходит именно здесь, и пересчитывает числа, на которых это решение стоит, на каждой сборке.

77
компонентов ядра
136
путей экспорта
0
runtime-зависимостей у ядра
12
пакетов в семействе

Почему группы каталога — не границы пакетов

Каталог делит компоненты на группы — «Действия», «Формы», «Данные», «Навигация», — и группы выглядят готовыми границами пакетов. Они ими не являются: группы отвечают на «где искать компонент», а граф зависимостей — на «кто кого рендерит», и эти два вопроса не совпадают.

78
рёбер графа рендера
56 (72%)
из них пересекают границы групп
4
глубина графа
32
компонентов без зависимостей

Рёбра, пересекающие границу групп

Из чего собрано всё остальное

Разрежьте пакет по группам, и эти компоненты окажутся в каждом куске — или за peer-зависимостью каждого куска.

Каждое число этого раздела посчитано по установленному пакету: зависимости — из granular-провайдера, группы — из реестра. Документ библиотеки приводит тот же аргумент, снятый на более старой версии, — ровно поэтому эта страница мерит, а не цитирует.

Как импорт доходит до бандла

Гранулярность — не обещание про tree-shaking, а форма пакета: подпуть на компонент, entry на подпуть и CSS внутри чанка самого компонента.

  1. Вы импортируете подпуть
  2. сборщик берёт его entry и его граф
  3. CSS компонента едет в том же чанке
  4. пресет UnoCSS эмитит утилиты для перечисленных компонентов, и только для них

Ядро и спутники

Ядро несёт компоненты общего назначения. Всё, что тянет тяжёлую зависимость, принадлежит своей предметной области или нужно меньшинству, живёт в пакете-спутнике с peer-зависимостью на ядро.

Это и есть единственное условие пересмотра решения «пакет один»: у семейства компонентов появляется тяжёлая внешняя зависимость, не нужная остальным. Ровно поэтому уехали графики, даты, редактор, медиа и дашборд.

Где библиотека заканчивается

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

Дальше

Полный разбор с историей решения — в репозитории библиотеки.

Посчитано на сборке по @feugene/granularity 0.41.0