Hash, Chunkhash и Contenthash

Свободный перевод: https://medium.com/@sahilkkrazy/hash-vs-chunkhash-vs-contenthash-e94d38a32208

Введение

Недавно я просматривал некоторые темы Github и увидел, что многие люди не совсем понимают разницу между «hash, chunkhash и contenthash». Поэтому я подумал о том, чтобы попытаться уточнить это. В этой статьи вы узнаете следующие:

1. Почему мы нуждаемся в хешировании.
2. Типы хеширования.
3. Объяснение каждого типа.
4. Срезы хешей.

Почему мы нуждаемся в хешировании

Давайте попробуем понять, зачем нам нужна концепция хэшей. Для каждого разрабатываемого приложения мы стараемся использовать «долгосрочное кеширование статического контента». Это позволяет значительно уменьшить время загрузки сайта. Но негативная сторона кеширования заключается в том что, пользователь не сможет видеть обновленные функции. Вместо новой версии будет загружаться старая из кеша. Поэтому традиционно мы добавляли версию или какое либо новое число для каждого файла в его пути для новой сборке, как то так:

app.js?build=1
vendor.css?build=1
main.css?build=1

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

Типы хеширования

Webpack предоставляет три типа хеширования:

1. [hash]
2. [сhunkhash]
3. [сontenthash]

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

Примеры использования: В качестве использования всех трех типов хешей будет использовать один конфиг в котором будет менять только тип хеша.

entry: {
  index: ["./src/index.js", "./src/index.css"],
  vendors: ["./src/vendors.js"]
},
output: {
  filename: "[name].[hash].js"
}
plugins: [
  new MiniCssExtractPlugin({
    filename: "[name].[hash].css"
  })
]

Hash

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

Результат

index.155567618f4367cd1cb8.css 1.43 kB 0 [emitted] index
index.155567618f4367cd1cb8.js 1.43 kB 0 [emitted] index
vendor.155567618f4367cd1cb8.js 1.43 kB 1 [emitted] vendor

Chunkhash

Chunkhash основан на точке входа webpack. Каждый определенный файл (или запись в конфиги) будет иметь свой собственный хеш. Если что-то изменится для этой конкретной точки входа, изменится только соответствующий хеш.

Результат:

index.155567618f4367cd1cb8.css 1.43 kB 0 [emitted] index
index.155567618f4367cd1cb8.js 1.43 kB 0 [emitted] index
vendor.c2330c22cd2decb5da5a.js 1.43 kB 1 [emitted] vendor

Но как видите, 1-й и 2-й файлы были взяты из одного и того же index, поэтому они имеют одинаковый хэш в своем имени. Это потому, что [chunkhash] генерируется на основе всего содержимого чанка. Поэтому, если я отредактирую, скажем, index.css и пересоберу сбоку, все файлы index из чанка, будет иметь новый хеш, но из чанка vendor останется таким же, как и прежде.

Contenthash

Contenthash — это особый тип хэша, рассчитываемый на основе контента файла.

Результат:

У каждого файла будет свой уникальный хеш.

index.155567618f4367cd1cb8.css 1.43 kB 0 [emitted] index
index.72342734682734fcd1b6.js 1.43 kB 0 [emitted] index
vendor.c2330c22cd2decb5da5a.js 1.43 kB 1 [emitted] vendor

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

Совет: Не используйте [chunkhash] в среде разработке, так как он увеличит время компиляции. Разделяйте конфиги разработки и производства и используйте [name].js для разработки и [name].[chunkhash].js в производстве.

Срезы хешей

Веб-пакет также позволяет использовать срезы хэшей. Если вы напишите [hash:8] вместо [hash], вы получите 8c4cbfdb вместо 8c4cbfdb91ff93f3f3c5.