Именование чанков

При сборке приложения Parcel анализирует граф зависимостей и формирует один или несколько выходных файлов. Каждый такой файл, содержащий код JavaScript, называется чанком (chunk). Чанки создаются автоматически на основе структуры проекта, механизма разделения кода (Code Splitting), динамических импортов и конфигурации сборки.

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

Автоматическое именование чанков

По умолчанию Parcel самостоятельно генерирует имена выходных файлов.

Пример исходного файла:

// src/index.js

import './app.js';

После сборки могут появиться файлы:

dist/
├── index.8f3d2a.js
├── app.1b7e9c.js
└── index.html

Здесь:

index — базовое имя ресурса;
8f3d2a — хеш содержимого;
.js — расширение файла.

Хеш обеспечивает уникальность имени и позволяет браузеру автоматически загружать новую версию файла после изменения кода.

Назначение хешей в именах чанков

Основная задача хеширования — поддержка долгосрочного кэширования.

Без хеша:

app.js

После обновления приложения браузер может продолжать использовать старую версию файла из кэша.

С хешем:

app.a1b2c3.js

После изменения содержимого:

app.f4e5d6.js

Поскольку имя изменилось, браузер воспринимает файл как новый ресурс и загружает его заново.

Преимущества:

автоматическое обновление кэша;
уменьшение количества сетевых запросов;
повышение производительности приложения;
отсутствие необходимости вручную очищать кэш.

Чанки при динамическом импорте

Одним из самых распространённых способов создания дополнительных чанков является использование динамического импорта.

Пример:

button.addEventListener('click', async () => {
    const module = await import('./editor.js');
    module.start();
});

Parcel создаст отдельный файл для модуля:

index.a12f34.js
editor.b45c67.js

Основной код будет загружен сразу, а код редактора — только при необходимости.

С точки зрения именования Parcel автоматически выбирает имя на основе исходного файла и внутреннего графа зависимостей.

Общие принципы формирования имён

При создании имени чанка Parcel учитывает:

Имя входного файла.
Тип ресурса.
Граф зависимостей.
Наличие нескольких точек входа.
Конфигурацию выходного каталога.
Использование хеширования.

Например:

src/
├── index.js
├── dashboard.js
└── admin.js

Результат может выглядеть так:

index.abc123.js
dashboard.def456.js
admin.ghi789.js

Если между ними существуют общие зависимости, Parcel дополнительно создаст общий чанк:

common.jkl012.js

или другое автоматически выбранное имя.

Именование через package.json

Parcel позволяет задавать шаблон имени выходных файлов через поле targets.

Пример:

{
  "targets": {
    "default": {
      "distDir": "dist",
      "publicUrl": "/",
      "outputFormat": "esmodule"
    }
  }
}

Хотя прямого аналога настройки chunkFilename, как в Webpack, Parcel не предоставляет, структура имени определяется системой целей (targets), типом ресурса и внутренними механизмами сборщика.

Философия Parcel заключается в минимизации ручной настройки и автоматическом выборе оптимальных имён.

Использование шаблона имени файлов

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

Пример:

{
  "targets": {
    "main": {
      "source": "src/index.js",
      "distDir": "dist",
      "outputFormat": "commonjs"
    }
  }
}

Результатом может стать:

dist/index.js

или

dist/index.[hash].js

в зависимости от режима сборки.

Влияние режима сборки на имена чанков

Development

Во время разработки имена обычно более читаемы:

index.js
settings.js
profile.js

или

index.1234.js

Основной акцент делается на удобство отладки.

Production

В production Parcel оптимизирует выходные файлы:

index.a72fd4.js
vendors.93d7b1.js
profile.c53fa8.js

Здесь появляется более активное использование хеширования для эффективного кэширования.

Shared Chunks и их именование

Parcel автоматически выделяет общий код в отдельные чанки.

Пример:

// dashboard.js
import React from 'react';

// profile.js
import React from 'react';

Обе страницы используют одну библиотеку.

Parcel может создать структуру:

dashboard.a12.js
profile.b34.js
react.c56.js

или

dashboard.a12.js
profile.b34.js
shared.c56.js

Точное имя определяется внутренним алгоритмом сборщика.

Главная цель — избежать дублирования кода.

Как Parcel определяет имя общего чанка

Для общих модулей Parcel анализирует:

количество импортов;
размер модуля;
взаимосвязь между точками входа;
необходимость оптимизации загрузки.

Например:

import lodash from 'lodash';

используется в нескольких частях приложения.

Возможный результат:

lodash.8a1d2f.js

Либо:

shared.8a1d2f.js

Название не гарантируется и может изменяться между версиями Parcel.

Поэтому не следует полагаться на конкретные имена автоматически созданных чанков.

Стабильность имён и долгосрочное кэширование

Для долгосрочного хранения файлов в CDN важна стабильность имён.

Пример:

app.2f3d4e.js

Если код не изменился, Parcel старается сохранить тот же хеш.

Если был изменён только один модуль:

app.7c8d9e.js

изменится только соответствующий файл.

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

уменьшить объём повторных загрузок;
сократить нагрузку на сервер;
ускорить работу приложения.

Разделение точек входа и именование чанков

Parcel поддерживает несколько входных файлов.

Пример:

parcel build src/home.html src/admin.html

Возможная структура:

dist/
├── home.html
├── admin.html
├── home.a12.js
├── admin.b34.js
└── shared.c56.js

Каждая точка входа получает собственный набор чанков.

Имена чанков для Web Workers

При использовании Web Workers Parcel создаёт отдельные файлы.

Пример:

const worker = new Worker(
    new URL('./worker.js', import.meta.url),
    { type: 'module' }
);

Результат сборки:

index.a12.js
worker.b34.js

Файл воркера становится отдельным чанком и получает собственное имя.

Именование чанков для Service Workers

Аналогичный принцип применяется к Service Worker.

Исходный код:

navigator.serviceWorker.register(
    new URL('./sw.js', import.meta.url)
);

После сборки:

index.a12.js
sw.c45.js

Service Worker получает отдельный файл и отдельный хеш.

Чанки ресурсов разных типов

Parcel работает не только с JavaScript.

Пример:

import './styles/main.css';

Результат:

index.a12.js
main.b34.css

Для изображений:

import logo from './logo.png';

После сборки:

logo.89f2d1.png

Для шрифтов:

font.7ab32c.woff2

Каждый ресурс получает имя по аналогичным правилам.

Анализ структуры выходных файлов

После сборки рекомендуется анализировать каталог dist.

Пример:

dist/
├── index.html
├── index.1a2b3c.js
├── dashboard.4d5e6f.js
├── shared.7g8h9i.js
├── styles.a1b2c3.css
└── logo.d4e5f6.svg

По именам файлов можно определить:

основные точки входа;
динамически загружаемые части;
общие зависимости;
тип ресурса;
наличие хеширования.

Практические рекомендации

Использовать динамические импорты для логического разделения

await import('./analytics.js');

Так создаются независимые чанки с понятной структурой.

Не привязываться к автоматически созданным именам

Нежелательно писать код вида:

fetch('/shared.js');

После сборки файл может называться иначе:

shared.a12b34.js

или

vendor.9c8d7e.js

Использовать ссылки, генерируемые Parcel

Правильно:

import image from './logo.png';

Неправильно:

const image = '/logo.png';

Parcel самостоятельно подставит актуальное имя ресурса.

Не отключать хеширование в production

Хеши являются важнейшим элементом кэширования:

app.f8d3c1.js

Они позволяют безопасно публиковать новые версии приложения без конфликтов со старыми файлами в браузерном кэше.

Особенности именования в крупных проектах

В больших приложениях количество чанков может исчисляться десятками и сотнями.

Пример структуры:

main.a12.js
profile.b34.js
settings.c56.js
editor.d78.js
analytics.e90.js
vendors.f12.js
shared.g34.js

Подобная организация позволяет:

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

Parcel автоматически управляет именованием этих файлов, формируя уникальные и предсказуемые для системы сборки идентификаторы, что избавляет от необходимости вручную поддерживать сложные схемы именования чанков.