От автора: в предлагаемой статье будут рассмотрены различные проблемы при работе с файлами и проектами, а также различные способы их решения с помощью сборщиков JavaScript.
Проблема №1 — Слишком много тегов скрипта
Первоначально интерфейс JavaScript не имел модульной системы, поэтому каждый файл JavaScript, который вы использовали, должен был быть включен с тегом сценария, и они должны были быть в правильном порядке… это было утомительно. Поэтому разработчики решили, что проще всего хранить весь ваш код в одном файле с одним тегом сценария, но файлы стали огромными, и с ними было трудно работать.
Решение №1 — Сборщики
Решением были JavaScript сборщики, такие как Browserify, которые брали несколько файлов JavaScript и «связывали» их в один файл, который можно было включить с тегом сценария.
Проблема № 2 — Более сложный процесс сборки
Так как процессы сборки стали более сложными, часто код проходит через несколько шагов сборки:
убедится, что весь код JavaScript верный с предпочтительными грамматическими ограничениями, используя ESLint
преобразовать черновой JavaScript в JavaScript, совместимый с браузером, с помощью Babel или перевести код TypeScript в JavaScript с помощью компилятора Typescript
перевести любые стили, написанные на Sass, в CSS
объединить свой код в один файл JavaScript внешнего интерфейса с помощью browserify
минимизировать код для оптимизации размера пакета
Решение 2.0 — Средство выполнения задач
Первоначальным решением были Task Runners, такие как Gulp и Grunt, с помощью которых вы могли планировать порядок задач для запуска этих процессов. Это было нормально, но потом пришло кое-что еще …
Решение 2.5 — Webpack
Webpack был сборщиком, который также можно использовать для управления всем конвейером сборки (запускать задачи). Таким образом, вы можете указать код для объединения, с помощью плагинов и модулей создать целую цепочку действий, которые нужно выполнить (например, lint, transpile, компиляция CSS). Webpack значительно упростил настройку с помощью богатой экосистемы плагинов и по-прежнему доминирует сегодня.
Однако не все проблемы были устранены, поэтому спрос на другие сборщики все еще существовал.
Проблема № 3 — Размер связки
Некоторые из самых популярных библиотек во всем JavaScript — это lodash и jQuery, которые предоставляют всевозможные полезные утилиты. Но обе эти библиотеки очень большие, и даже если вы включаете их только для использования одной функции, вы в конечном итоге включаете всю библиотеку в свой пакет, что влияет на производительность.
Решение № 3 — Tree Shaking
На сцену вышел новый пакет под названием Rollup с классной новой функцией под названием «Tree Shaking». Tree Shaking позволил вам объединить только то, что вы использовали. Поэтому, если вы использовали только одну функцию Lodash, тогда в ваш пакет будет включена только эта функция, а не вся библиотека.
Эта функция теперь является стандартной для сборщиков пакетов, но Rollup был новатором в решении этой проблемы.
Проблема №4 — Настройка Webpack и Rollup сложна и занимает много времени
Настроить все конфигурации для Webpack и Rollup действительно нужно только один раз, но это может занять много времени и быть сложным для правильной настройки.
Решение №4 — Parcel
Parcel зарекомендовала себя как сборщик «без конфигурации». Встраивая в себя многие из наиболее распространенных значений по умолчанию, она создала инструмент, позволяющий очень легко создавать среду сборки. Конечно, загвоздка в том, что если значения по умолчанию вам не подходят, то часто возврат к Webpack или Rollup может быть правильным вариантом.
Проблема № 5 – Модульность и медленное время сборки
При запуске среды разработки такие пакеты, как Rollup, Webpack и Parcel, перестраивают весь проект после каждого сохранения. Это нормально на ранних стадиях, но по мере того, как ваш проект становится больше, повторное объединение вашего приложения может занять много времени.
Несмотря на то, что JavaScript в конечном итоге представил систему модулей внешнего интерфейса, люди по-прежнему будут объединять свой код для совместимости со старыми браузерами.
Решение # 5 — Snowpack и Vite
Доля рынка новых браузеров уменьшилась, и использование Internet Explorer, наконец, утихло настолько, что мы можем рассмотреть возможность использования модулей ES по-настоящему! Вдобавок к этому в новых браузерах есть новые функции, позволяющие загружать дифференциальную версию, поэтому вы можете загружать один файл JavaScript для новых браузеров, а другой — для старых. (найдите ключевое слово nomodule).
Так что новейшие сборщики, Snowpack и Vite, пользуются этим. Вместо того, чтобы объединять все ваше приложение в один файл, они компилируют их в отдельные модули. Теперь, когда ваш код обновляется, вместо того, чтобы перестраивать весь пакет, нужно только перестраивать отредактированный модуль, что обеспечивает гораздо более быструю и приятную разработку.
Надеюсь, вам понравилось это путешествие по истории, чтобы понять эволюцию сборщиков Javascript!
Автор: Alex Merced Coder
Источник: alexmercedcoder.medium.com
Редакция: Команда webformyself.
Читайте нас в Telegram, VK, Яндекс.Дзен