Размер приложения в экосистеме Globalize напрямую определяется тем, какие части функциональности подключаются и какие данные локализации включаются в сборку. Библиотека построена вокруг модульной архитектуры, где ядро отделено от наборов локализационных данных CLDR и специализированных форматов (числа, даты, валюты, сообщения). Такой подход позволяет контролировать итоговый вес, но требует понимания структуры зависимостей.
Globalize разделяет функциональность на несколько слоёв:
Каждый слой существует независимо и подключается только при необходимости. Это означает, что минимальная сборка может включать только числовое форматирование, а полноценная интернационализация — десятки мегабайт локализационных данных при неправильной конфигурации.
Ключевой принцип: размер приложения определяется не библиотекой, а выбранными локалями и типами данных.
Centralized Unicode Locale Data Repository (CLDR) является основой Globalize. Он содержит:
CLDR представлен в виде JSON-файлов, и именно они формируют основную массу итогового бандла.
Типичная ошибка — подключение всех доступных локалей:
В таком случае даже минимальное приложение может увеличиться на сотни килобайт или мегабайты.
Globalize строго отделяет код библиотеки от данных локализации.
Runtime слой:
Data слой:
Такое разделение позволяет:
Однако эффективность зависит от сборщика и стратегии импорта.
Современные сборщики (Webpack, Rollup, Vite) позволяют исключать неиспользуемые части Globalize при корректном ESM-импорте.
Пример влияния импорта:
Факторы, влияющие на tree-shaking:
При неправильной конфигурации tree-shaking не работает, и в сборку попадает весь runtime слой, даже если используется одна функция форматирования чисел.
Наиболее эффективный способ управления размером — динамическая загрузка локалей.
Локали могут:
Подход позволяет разделить приложение на:
Это особенно критично для приложений с поддержкой десятков языков.
Основной принцип: загружать только те локали, которые реально используются пользователем.
Globalize предоставляет независимые модули:
Подключение только одного типа функциональности существенно снижает размер.
Например:
Каждый дополнительный модуль увеличивает потребление памяти и размер бандла за счёт дополнительных правил и данных.
Модуль сообщений использует правила плюрализации, основанные на CLDR.
Это означает:
Сообщения с ICU-структурой могут значительно увеличить размер приложения, особенно при поддержке множества языков.
Снижение размера достигается за счёт:
Часто применяется стратегия “locale whitelist”, где явно перечисляются поддерживаемые языки.
Пример логики:
Все остальные локали исключаются на этапе сборки.
Размер итогового приложения сильно зависит от инструментов сборки:
Ошибки конфигурации приводят к включению:
что полностью нивелирует преимущества модульности.
Оптимальная архитектура включает:
Приложение разделяется на логические блоки:
Такой подход позволяет удерживать первоначальный размер минимальным, а расширение функциональности происходит по мере использования.
Увеличение функциональности Globalize всегда связано с ростом размера, поскольку интернационализация требует данных, а не только кода.
Основные источники роста:
Снижение размера достигается не удалением кода, а ограничением набора данных и точечным импортом модулей.