Два года назад я писал о методике, которую сейчас обычно называют паттерном module/nomodule. Её применение позволяет писать JavaScript-код, используя возможности ES2015+, а потом применять бандлеры и транспиляторы для создания двух версий кодовой базы. Одна из них содержит современный синтаксис (она загружается с помощью конструкции вида
Раньше, даже учитывая возможность отправлять современный JavaScript-код в продакшн, и даже хотя большинство браузеров поддерживало модули, я рекомендовал собирать код в бандлы.
Почему? В основном — потому, что у меня было ощущение того, что загрузка модулей в браузер была медленной. Даже несмотря на то, что свежие протоколы, вроде HTTP/2, теоретически поддерживали эффективную загрузку множества файлов, все исследования производительности в то время приходили к выводу о том, что использование бандлеров всё ещё более эффективно, чем использование модулей.
Но надо признать, что те исследования были неполными. Тестовые примеры с использованием модулей, которые в них изучались, состояли из неоптимизированных и неминифицированных файлов исходного кода, которые развёртывались в продакшне. Не проводилось сравнений оптимизированного бандла с модулями с оптимизированным классическим скриптом.
Однако, честно говоря, тогда не было некоего оптимального способа развёртывания модулей. Но сейчас, благодаря некоторым современным улучшениям в технологиях бандлеров, можно развёртывать продакшн-код в виде ES2015-модулей с использованием и статических, и динамических команд импорта, и получать при этом производительность более высокого уровня, чем можно достичь с применением доступных вариантов, в которых модули не используются.
Надо отметить, что на сайте, на котором опубликован оригинал материала, первую часть перевода которого мы сегодня публикуем, модули уже несколько месяцев используются в продакшне.
Многие люди, с которыми мне доводилось беседовать, полностью отвергают модули, не рассматривая их даже как один из вариантов для крупномасштабных продакшн-приложений. Многие из них цитируют то самое исследование, которое я уже упоминал. А именно — ту его часть, в которой говорится о том, что модули в продакшне использовать не следует, если только речь не идёт о «маленьких веб-приложениях, в которые входит менее 100 модулей, отличающихся сравнительно «мелким» деревом зависимостей (то есть — таким, глубина которого не превышает 5 уровней)».
Если вы когда-нибудь заглядывали в директорию
Здесь-то и коренится главное заблуждение, касающееся модулей. Программисты полагают, что, когда дело доходит до использования модулей в продакшне, у них есть всего два варианта. Первый — развёртывать весь исходный код в его существующем виде (включая директорию
Однако если присмотреться к рекомендации из процитированного выше исследования, можно обнаружить, что там ничего не сказано о том, что загрузка модулей — это медленнее, чем загрузка обычных скриптов. Там ничего не говорится о том, что модули вообще не надо использовать. Там лишь идёт речь о том, что если некто разворачивает сотни неминифицированных файлов модулей в продкашне, Chrome не сможет загрузить их так же быстро, как единственный минифицированный бандл. В результате исследование советует продолжать использовать бандлеры, компиляторы и минификаторы.
Но знаете что? Дело в том, что можно и применять всё это, и использовать модули в продакшне.
На самом деле, модули — это формат, к преобразованию к которому кода нам стоит стремиться, так как браузеры уже знают о том, как загружать модули (а браузеры, которые этого не могут, способны загрузить запасной вариант кода с использованием механизма nomodule). Если вы посмотрите код, который генерируют самые популярные бандлеры, то вы обнаружите множество шаблонных фрагментов, цель которых заключается лишь в том, чтобы динамически загружать другой код и управлять зависимостями. Но всё это будет не нужно в том случае, если мы просто будем пользоваться модулями и выражениями
К счастью, по крайней мере один из популярных современных бандлеров (Rollup) поддерживает модули в виде формата выходных данных. Это означает, что можно и обрабатывать бандлером код, и разворачивать в продакшне модули (без использования шаблонных фрагментов для загрузки кода). И, так как в Rollup имеется прекрасная реализация алгоритма tree-shaking (лучшая из тех, что мне доводилось видеть в бандлерах), сборка программ в виде модулей с использованием Rollup позволяет получать код, размеры которого меньше, чем размеры аналогичного кода, полученного при применении других доступных сегодня механизмов.
Надо отметить, что поддержку модулей планируют добавить в следующую версию Parcel. Webpack пока не поддерживает модули в качестве выходного формата, но вот, вот и вот — обсуждения, которые посвящены этому вопросу.
Ещё одно заблуждение, касающееся модулей, заключается в том, что некоторые полагают, что модули можно использоват�� только в том случае, если 100% зависимостей проекта использует модули. К сожалению (я считаю — к огромному сожалению), большинство npm-пакетов всё ещё готовятся к публикации использованием формата CommonJS (некоторые модули, даже написанные с использованием возможностей ES2015, перед публикацией в npm транспилируются в формат CommonJS)!
Тут, опять же, хочу отметить, что Rollup имеет плагин (rollup-plugin-commonjs), который принимает на вход исходный код, написанный с использованием CommonJS, и конвертирует его в ES2015-код. Определённо, лучше будет, если в используемых зависимостях с самого начала применяется формат модулей ES2015. Но если некоторые зависимости таковыми не являются, это не мешает разворачивать в продакшне проекты, использующие модули.
В следующих частях этого материала я собираюсь продемонстрировать вам то, как я собираю проекты в бандлы, использующие модули (включая применение динамических импортов и разделения кода), собираюсь рассказать о том, почему подобные решения обычно более производительны, чем классические скрипты, и показать методики работы с браузерами, которые не поддерживают модули.
Сборка кода для продакшна — это всегда попытка сбалансировать плюсы и минусы различных решений. С одной стороны — разработчику хочется, чтобы его код загружался и выполнялся бы как можно быстрее. С другой — ему не хочется загружать код, который не будет задействован пользователями проекта.
Кроме того, разработчикам нужна уверенность в том, что их код как можно лучше подходит для кэширования. Большая проблема бандлинга кода заключается в том, что любое изменение кода, даже одна изменённая строка, приводит к инвалидации кэша всего бандла. Если вы разворачиваете приложение, состоящее из тысяч маленьких модулей (представленных в точности в том виде, в котором они присутствуют в исходном коде), тогда вы можете спокойно вносить в код мелкие изменения и при этом знать о том, что большая часть кода приложения окажется кэшированной. Но, как я уже говорил, такой подход к разработке, вероятно, может означать и то, что загрузка кода при первом посещении ресурса может занять больше времени, чем при использовании более традиционных подходов.
В результате перед нами стоит непростая задача, которая заключается в том, чтобы найти правильный подход к разбиению бандлов на части. Нам нужно выйти на правильный баланс между скоростью загрузки материалов и их долговременным кэшированием.
Большинство бандлеров, по умолчанию, применяют техники разделения кода с учётом команд динамического импорта. Но я бы сказал, что разделение кода лишь с ориентацией на динамический импорт не позволяет разбить его на достаточно мелкие фрагменты. Особенно это справедливо для сайтов с множеством возвращающихся пользователей (то есть — в тех ситуациях, когда важно кэширование).
Я полагаю, что код стоит разбивать на настолько мелкие фрагменты, насколько это возможно. Уменьшать размер фрагментов стоит до тех пор, пока их количество возрастёт настолько, что это станет воздейст��овать на скорость загрузки проекта. И хотя я, определённо, рекомендую каждому выполнять собственный анализ ситуации, если верить приблизительным подсчётам, выполненным в упомянутом мной исследовании, при загрузке менее чем 100 модулей заметного замедления загрузки не наблюдается. Отдельное исследование, посвящённое производительности HTTP/2, не выявило заметного замедления проекта при загрузке менее чем 50 файлов. Там, правда, тестировали только варианты, в которых число файлов составляло 1, 6, 50 и 1000. В результате, вероятно, 100 файлов — это то значение, на которое вполне можно ориентироваться, не боясь потерять в скорости загрузки.
Итак, каков же лучший способ агрессивного, но при этом не слишком агрессивного разделения кода на части? В дополнение к разделению кода, основанного на командах динамического импорта, я посоветовал бы ещё присмотреться к разделению кода по npm-пакетам. При таком подходе то, что импортируется в проект из папки
Выше я сказал, что некоторые современные возможности бандлеров делают возможным организацию высокопроизводительной схемы развёртывания проектов, основанных на модулях. То, о чём я говорил, представлено двумя новыми возможностями Rollup. Первая — это автоматическое разделение кода через динамические команды
Благодаря этим двум возможностям теперь очень легко настроить процесс сборки, при котором выполняется разделение кода на уровне пакетов.
Вот пример конфигурации, в которой используется опция
Опция
Рассмотрим приложение, которое импортирует модули
В конце файла можно будет увидеть выражение экспорта наподобие следующего. Обратите внимание на то, что это выражение содержит только команды экспорта модулей, добавленных во фрагмент, а не всех модулей
Затем, если код в любом из других фрагментов использует эти модули
Надеюсь, этот пример прояснил вопрос о том, как работает ручное разделение кода в Rollup. Кроме того, я думаю, что результаты разделения кода, в которых используются выражения
Например, очень сложно разобраться в том, что происходит в следующем файле. Это — выходные материалы одного из моих старых проектов, в котором для разделения кода использовался webpack. Практически всё в этом коде не нужно в браузерах, поддерживающих модули.
Как я уже говорил, я считаю, что разделение кода на уровне пакетов обычно позволяет разработчику попасть в выгодную позицию, когда разделение кода ведётся агрессивно, но не слишком агрессивно.
Конечно, если ваше приложение импортирует модули из сотен различных npm-пакетов, вы всё ещё можете пребывать в ситуации, когда браузер не может эффективно их все загрузить.
Однако если у вас действительно имеется множество npm-зависимостей, вам не стоит пока совсем отказываться от этой стратегии. Помните о том, что вы, вероятно, не будете загружать все npm-зависимости на каждой странице. Поэтому важно выяснить то, сколько зависимостей загружается на самом деле.
Тем не менее, я уверен, что существуют некие реальные приложения, которые имеют так много npm-зависимостей, что эти зависимости просто невозможно представить в виде отдельных фрагментов. Если ваш проект именно таков — я порекомендовал бы вам поискать способ группировки пакетов, код в которых с высокой долей вероятности может меняться в одно и то же время (вроде
Продолжение следует…
Уважаемые читатели! Как вы подходите к проблеме разделения кода в своих проектах?
<script type="module">, а вторая — синтаксис ES5 (её загружают с помощью <script nomodule>). Паттерн module/nomodule позволяет отправлять в браузеры, поддерживающие модули, гораздо меньше кода, чем в браузеры, эту возможность не поддерживающие. Теперь этот паттерн поддерживает большинство веб-фреймворков и инструментов командной строки.Раньше, даже учитывая возможность отправлять современный JavaScript-код в продакшн, и даже хотя большинство браузеров поддерживало модули, я рекомендовал собирать код в бандлы.
Почему? В основном — потому, что у меня было ощущение того, что загрузка модулей в браузер была медленной. Даже несмотря на то, что свежие протоколы, вроде HTTP/2, теоретически поддерживали эффективную загрузку множества файлов, все исследования производительности в то время приходили к выводу о том, что использование бандлеров всё ещё более эффективно, чем использование модулей.
Но надо признать, что те исследования были неполными. Тестовые примеры с использованием модулей, которые в них изучались, состояли из неоптимизированных и неминифицированных файлов исходного кода, которые развёртывались в продакшне. Не проводилось сравнений оптимизированного бандла с модулями с оптимизированным классическим скриптом.
Однако, честно говоря, тогда не было некоего оптимального способа развёртывания модулей. Но сейчас, благодаря некоторым современным улучшениям в технологиях бандлеров, можно развёртывать продакшн-код в виде ES2015-модулей с использованием и статических, и динамических команд импорта, и получать при этом производительность более высокого уровня, чем можно достичь с применением доступных вариантов, в которых модули не используются.
Надо отметить, что на сайте, на котором опубликован оригинал материала, первую часть перевода которого мы сегодня публикуем, модули уже несколько месяцев используются в продакшне.
Ошибочные представления о модулях
Многие люди, с которыми мне доводилось беседовать, полностью отвергают модули, не рассматривая их даже как один из вариантов для крупномасштабных продакшн-приложений. Многие из них цитируют то самое исследование, которое я уже упоминал. А именно — ту его часть, в которой говорится о том, что модули в продакшне использовать не следует, если только речь не идёт о «маленьких веб-приложениях, в которые входит менее 100 модулей, отличающихся сравнительно «мелким» деревом зависимостей (то есть — таким, глубина которого не превышает 5 уровней)».
Если вы когда-нибудь заглядывали в директорию
node_modules какого-нибудь своего проекта, то вы, вероятно, знаете о том, что даже маленькое приложение легко может иметь более 100 модулей-зависимостей. Я хочу предложить вам взглянуть на то, как много модулей имеется в некоторых из самых популярных npm-пакетов.Здесь-то и коренится главное заблуждение, касающееся модулей. Программисты полагают, что, когда дело доходит до использования модулей в продакшне, у них есть всего два варианта. Первый — развёртывать весь исходный код в его существующем виде (включая директорию
node_modules). Второй — совсем не использовать модули.Однако если присмотреться к рекомендации из процитированного выше исследования, можно обнаружить, что там ничего не сказано о том, что загрузка модулей — это медленнее, чем загрузка обычных скриптов. Там ничего не говорится о том, что модули вообще не надо использовать. Там лишь идёт речь о том, что если некто разворачивает сотни неминифицированных файлов модулей в продкашне, Chrome не сможет загрузить их так же быстро, как единственный минифицированный бандл. В результате исследование советует продолжать использовать бандлеры, компиляторы и минификаторы.
Но знаете что? Дело в том, что можно и применять всё это, и использовать модули в продакшне.
На самом деле, модули — это формат, к преобразованию к которому кода нам стоит стремиться, так как браузеры уже знают о том, как загружать модули (а браузеры, которые этого не могут, способны загрузить запасной вариант кода с использованием механизма nomodule). Если вы посмотрите код, который генерируют самые популярные бандлеры, то вы обнаружите множество шаблонных фрагментов, цель которых заключается лишь в том, чтобы динамически загружать другой код и управлять зависимостями. Но всё это будет не нужно в том случае, если мы просто будем пользоваться модулями и выражениями
import и export.К счастью, по крайней мере один из популярных современных бандлеров (Rollup) поддерживает модули в виде формата выходных данных. Это означает, что можно и обрабатывать бандлером код, и разворачивать в продакшне модули (без использования шаблонных фрагментов для загрузки кода). И, так как в Rollup имеется прекрасная реализация алгоритма tree-shaking (лучшая из тех, что мне доводилось видеть в бандлерах), сборка программ в виде модулей с использованием Rollup позволяет получать код, размеры которого меньше, чем размеры аналогичного кода, полученного при применении других доступных сегодня механизмов.
Надо отметить, что поддержку модулей планируют добавить в следующую версию Parcel. Webpack пока не поддерживает модули в качестве выходного формата, но вот, вот и вот — обсуждения, которые посвящены этому вопросу.
Ещё одно заблуждение, касающееся модулей, заключается в том, что некоторые полагают, что модули можно использоват�� только в том случае, если 100% зависимостей проекта использует модули. К сожалению (я считаю — к огромному сожалению), большинство npm-пакетов всё ещё готовятся к публикации использованием формата CommonJS (некоторые модули, даже написанные с использованием возможностей ES2015, перед публикацией в npm транспилируются в формат CommonJS)!
Тут, опять же, хочу отметить, что Rollup имеет плагин (rollup-plugin-commonjs), который принимает на вход исходный код, написанный с использованием CommonJS, и конвертирует его в ES2015-код. Определённо, лучше будет, если в используемых зависимостях с самого начала применяется формат модулей ES2015. Но если некоторые зависимости таковыми не являются, это не мешает разворачивать в продакшне проекты, использующие модули.
В следующих частях этого материала я собираюсь продемонстрировать вам то, как я собираю проекты в бандлы, использующие модули (включая применение динамических импортов и разделения кода), собираюсь рассказать о том, почему подобные решения обычно более производительны, чем классические скрипты, и показать методики работы с браузерами, которые не поддерживают модули.
Оптимальная стратегия сборки кода
Сборка кода для продакшна — это всегда попытка сбалансировать плюсы и минусы различных решений. С одной стороны — разработчику хочется, чтобы его код загружался и выполнялся бы как можно быстрее. С другой — ему не хочется загружать код, который не будет задействован пользователями проекта.
Кроме того, разработчикам нужна уверенность в том, что их код как можно лучше подходит для кэширования. Большая проблема бандлинга кода заключается в том, что любое изменение кода, даже одна изменённая строка, приводит к инвалидации кэша всего бандла. Если вы разворачиваете приложение, состоящее из тысяч маленьких модулей (представленных в точности в том виде, в котором они присутствуют в исходном коде), тогда вы можете спокойно вносить в код мелкие изменения и при этом знать о том, что большая часть кода приложения окажется кэшированной. Но, как я уже говорил, такой подход к разработке, вероятно, может означать и то, что загрузка кода при первом посещении ресурса может занять больше времени, чем при использовании более традиционных подходов.
В результате перед нами стоит непростая задача, которая заключается в том, чтобы найти правильный подход к разбиению бандлов на части. Нам нужно выйти на правильный баланс между скоростью загрузки материалов и их долговременным кэшированием.
Большинство бандлеров, по умолчанию, применяют техники разделения кода с учётом команд динамического импорта. Но я бы сказал, что разделение кода лишь с ориентацией на динамический импорт не позволяет разбить его на достаточно мелкие фрагменты. Особенно это справедливо для сайтов с множеством возвращающихся пользователей (то есть — в тех ситуациях, когда важно кэширование).
Я полагаю, что код стоит разбивать на настолько мелкие фрагменты, насколько это возможно. Уменьшать размер фрагментов стоит до тех пор, пока их количество возрастёт настолько, что это станет воздейст��овать на скорость загрузки проекта. И хотя я, определённо, рекомендую каждому выполнять собственный анализ ситуации, если верить приблизительным подсчётам, выполненным в упомянутом мной исследовании, при загрузке менее чем 100 модулей заметного замедления загрузки не наблюдается. Отдельное исследование, посвящённое производительности HTTP/2, не выявило заметного замедления проекта при загрузке менее чем 50 файлов. Там, правда, тестировали только варианты, в которых число файлов составляло 1, 6, 50 и 1000. В результате, вероятно, 100 файлов — это то значение, на которое вполне можно ориентироваться, не боясь потерять в скорости загрузки.
Итак, каков же лучший способ агрессивного, но при этом не слишком агрессивного разделения кода на части? В дополнение к разделению кода, основанного на командах динамического импорта, я посоветовал бы ещё присмотреться к разделению кода по npm-пакетам. При таком подходе то, что импортируется в проект из папки
node_modules, попадает в отдельный фрагмент готового кода на основании имени пакета.Разделение кода на уровне пакетов
Выше я сказал, что некоторые современные возможности бандлеров делают возможным организацию высокопроизводительной схемы развёртывания проектов, основанных на модулях. То, о чём я говорил, представлено двумя новыми возможностями Rollup. Первая — это автоматическое разделение кода через динамические команды
import() (добавлена в v1.0.0). Вторая возможность — это ручное разделение кода, выполняемое программой на основании опции manualChunks (добавлена в v1.11.0).Благодаря этим двум возможностям теперь очень легко настроить процесс сборки, при котором выполняется разделение кода на уровне пакетов.
Вот пример конфигурации, в которой используется опция
manualChunks, благодаря которой каждый модуль, импортированный из node_modules, попадает в отдельный фрагмент кода, имя которого соответствует имени пакета (технически — имени директории пакета в папке node_modules):export default { input: { main: 'src/main.mjs', }, output: { dir: 'build', format: 'esm', entryFileNames: '[name].[hash].mjs', }, manualChunks(id) { if (id.includes('node_modules')) { // Возвращает имя директории, идущей после последнего `node_modules`. // Обычно это - пакет, хотя это может быть и пространством имён. const dirs = id.split(path.sep); return dirs[dirs.lastIndexOf('node_modules') + 1]; } }, }
Опция
manualChunk принимает функцию, которая принимает, в качестве единственного аргумента, путь к файлу модуля. Эта функция может возвратить строковое имя. То, что она возвратит, укажет на фрагмент сборки, к которому должен быть добавлен текущий модуль. Если функция не возвращает ничего — то модуль будет добавлен во фрагмент, используемый по умолчанию.Рассмотрим приложение, которое импортирует модули
cloneDeep(), debounce() и find() из пакета lodash-es. Если применить при сборке этого приложения вышеприведённую конфигурацию, то каждый из этих модулей (а так же каждый модуль lodash, импортируемый этими модулями) будет помещён в единственный выходной файл с именем наподобие npm.lodash-es.XXXX.mjs (здесь XXXX — это уникальный хэш файла модулей во фрагменте lodash-es).В конце файла можно будет увидеть выражение экспорта наподобие следующего. Обратите внимание на то, что это выражение содержит только команды экспорта модулей, добавленных во фрагмент, а не всех модулей
lodash.export {cloneDeep, debounce, find};
Затем, если код в любом из других фрагментов использует эти модули
lodash (возможно — лишь метод debounce()), в этих фрагментах, в их верхней части, будет иметься выражение импорта, выглядящее так:import {debounce} from './npm.lodash.XXXX.mjs';
Надеюсь, этот пример прояснил вопрос о том, как работает ручное разделение кода в Rollup. Кроме того, я думаю, что результаты разделения кода, в которых используются выражения
import и export, гораздо легче читать и понимать, чем код фрагментов, при формировании которых применялись нестандартные механизмы, использующиеся только в некоем бандлере.Например, очень сложно разобраться в том, что происходит в следующем файле. Это — выходные материалы одного из моих старых проектов, в котором для разделения кода использовался webpack. Практически всё в этом коде не нужно в браузерах, поддерживающих модули.
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([["import1"],{ /***/ "tLzr": /*!*********************************!*\ !*** ./app/scripts/import-1.js ***! \*********************************/ /*! exports provided: import1 */ /***/ (function(module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); /* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, "import1", function() { return import1; }); /* harmony import */ var _dep_1__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./dep-1 */ "6xPP"); const import1 = "imported: " + _dep_1__WEBPACK_IMPORTED_MODULE_0__["dep1"]; /***/ }) }]);
Как быть, если имеются сотни npm-зависимостей?
Как я уже говорил, я считаю, что разделение кода на уровне пакетов обычно позволяет разработчику попасть в выгодную позицию, когда разделение кода ведётся агрессивно, но не слишком агрессивно.
Конечно, если ваше приложение импортирует модули из сотен различных npm-пакетов, вы всё ещё можете пребывать в ситуации, когда браузер не может эффективно их все загрузить.
Однако если у вас действительно имеется множество npm-зависимостей, вам не стоит пока совсем отказываться от этой стратегии. Помните о том, что вы, вероятно, не будете загружать все npm-зависимости на каждой странице. Поэтому важно выяснить то, сколько зависимостей загружается на самом деле.
Тем не менее, я уверен, что существуют некие реальные приложения, которые имеют так много npm-зависимостей, что эти зависимости просто невозможно представить в виде отдельных фрагментов. Если ваш проект именно таков — я порекомендовал бы вам поискать способ группировки пакетов, код в которых с высокой долей вероятности может меняться в одно и то же время (вроде
react и react-dom) так как инвалидация кэша фрагментов с этими пакетами тогда тоже будет выполняться в одно и то же время. Позже я покажу пример, в котором все React-зависимости группируются в одном и том же фрагменте.Продолжение следует…
Уважаемые читатели! Как вы подходите к проблеме разделения кода в своих проектах?
