Js bundle: Зачем и где все это нужно bundle.js?

Содержание

Зачем и где все это нужно bundle.js?

Какая потребность в bundle.js для Node.js/Angular/React приложений? Что делать, если он не используется при создании и развертывании приложения?

javascript

angularjs

node.js

reactjs

Поделиться

Источник


Ashfaque Rifaye    

09 декабря 2018 в 07:08

2 ответа


  • Github: зачем мне это нужно?

    Я все еще совершенно не уверен, как его использовать, но я только что скачал Git и настраивал его в соответствии с их веб-страницей . В разделе о кэшировании паролей говорится, что если мне не нужно каждый раз вводить свой пароль, я могу использовать Github для Windows. Я был сбит с толку, поэтому…

  • вложенный конструктор. Зачем это нужно?

    class Character(Entity): def __init__(self, x, y, hp): Entity.__init__(self, x, y) self.hp = hp self.items = [] Character является дочерним классом родительского класса Entity . Entity класс также имеет функцию __init__ . Зачем нужно писать обе функции __init__ ? Почему бы не написать только…



7

Откуда берется пакетирование?

Мы начали объединять наши активы из соображений производительности.

  • HTTP1 поддерживает ограниченные запросы на одно соединение. Создание соединений для каждого актива убивало производительность.
  • Мы начали связывать вещи страница за страницей, чтобы увеличить производительность с более эффективным кэшированием.
  • Мы смогли добавить к нему отпечаток пальца и загрузить его в CDN. (главная-page.231434.js). Таким образом, мы смогли развернуть наше приложение, докеризовав его.
  • Пакетирование также помогает нам уменьшить размер страницы больше, потому что bundler знает всю систему. Это означает, что он может удалять неиспользуемые вещи и уменьшать их легче. Вы не можете сделать это без бандлера легко.
  • Также, пакетов, используется transpilers. Браузеры не всегда могут запускать коды, которые мы пишем, например Typescript, CoffeeScript. Bundlers могут легко транспилировать эти коды в пакеты.

Нам это все еще нужно?

В наше время все меняется очень много, как мы bundle наших активов.

  • Во-первых, почти каждый браузер теперь поддерживает HTTP/2., поэтому мы можем запрашивать несколько файлов по одному и тому же соединению. Связывание больше не требуется из-за этого. Кроме того, у нас есть http/2 серверный толчок.
  • Библиотеки, такие как React, Angular, Vue, намного более эффективны по размеру. Они могут быть легко загружены на страницу из источника поддержки gzip.

Вот почему мы больше не нуждаемся в связывании.

Но на основе вашего проекта нам все еще может понадобиться пакетирование. Это истинная правда.

Я бы все равно пошел с укутыванием.


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

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

Поделиться


Ahmet Can Güven    

09 декабря 2018 в 08:02



1

В настоящее время мы обычно используем пакетные инструменты,такие как webpack, чтобы упаковать js,css или другие файлы. С помощью правильных загрузчиков webpack упакует файлы во многие файлы bundle, и браузер поймет их.

  1. Модуль bundler проанализирует проект ,найдет зависимость и только при загрузке веб — страницы получит необходимый пакет.
  2. А с модулем bundler он будет компилятором некоторых языков, которые браузер не может прочитать, например typescript 、less и так далее.

Модуль bundler не является необходимым для веб-проекта, но он будет улучшать производительность веб-страниц. Если вы не используете модуль bundler, web не может получить только необходимый bundle при загрузке. Так что время загрузки будет больше.

Поделиться


Root    

09 декабря 2018 в 07:43


Похожие вопросы:

что такое silverlight developer runtime ? и зачем нам это нужно?

Я хочу узнать более подробно о времени выполнения разработчика silverlight что такое silverlight developer runtime ? и зачем нам это нужно ?

Зачем это нужно OrderedDictionary, ListDictionary, и HybridDictionary?`

Зачем нужны три разных словаря — OrderedDictionary,ListDictionary и HybridDictionary, когда все они выполняют сходные функции? Ни один из них не сортируется, и элементы коллекции могут быть…

Что значит делегировать? Зачем нам это нужно?

Возможный Дубликат : Делегаты, can’t соберитесь с мыслями Привет друзья, Что значит делегировать в objective C? Зачем нам это нужно? Когда мы должны использовать его? Есть ли в нем какие-нибудь…

Github: зачем мне это нужно?

Я все еще совершенно не уверен, как его использовать, но я только что скачал Git и настраивал его в соответствии с их веб-страницей . В разделе о кэшировании паролей говорится, что если мне не нужно…

вложенный конструктор. Зачем это нужно?

class Character(Entity): def __init__(self, x, y, hp): Entity.__init__(self, x, y) self.hp = hp self.items = [] Character является дочерним классом родительского класса Entity . Entity класс также…

webpack: нужно ли устанавливать webpack для использования bundle.js

Я установил webpack локально, загружаю bundle.js на сервер и вызываю его с помощью тега script с сервера index.html . Делая это, bundle.js не может вызвать модуль jquery внутри самого bundle….

Зачем все это нужно для JSON?

Я изучаю JSON, и я получил его, чтобы работать, но я хочу знать WHY это работает и как это работает. Я не понимаю, зачем нужны некоторые линии и что они делают. Ниже приведен мой основной cs и мой…

Что такое тряска дерева и зачем мне это нужно?

Я начал изучать Angular 2 и наткнулся на этот термин tree shaking, и я не смог найти никакого хорошего объяснения этому с точки зрения начинающих. У меня есть два вопроса : Что такое тряска дерева и…

Создайте отдельный bundle.js для каждого html (форма)

В настоящее время я работаю над проектом react SPA, где мне нужно сделать несколько форм с логикой. Каждая форма имеет одинаковые компоненты и некоторые уникальные. Теперь: когда клиент выберет одну…

Где bundle.js проекта реагируют

Я создал проект с create-react-app ,он может правильно работать на http://localhost:3000 , но мне нужно установить кросс-домен с nginx, конфигурация nginx выглядит следующим образом: server { listen…

Представляем Bundle Renderer | Руководство Vue SSR

Проблемы с обычным SSR

До этого момента мы предполагали, что сборка с кодом серверной части будет напрямую использоваться сервером через require:

Выглядит просто, однако всякий раз, когда вы редактируете исходный код вашего приложения, вам понадобится остановить и перезапустить сервер. Это очень плохо влияет на производительность во время разработки. К тому же, Node.js не поддерживает source maps нативно.

Добавляем BundleRenderer

vue-server-renderer предоставляет API, названное createBundleRenderer для решения этой проблемы. С помощью Webpack-плагина, серверная сборка создаётся как специальный JSON-файл, который может быть передан в рендерер. Как только рендерер создан, использование не будет отличаться от обычного рендерера, но появятся некоторые преимущества:

  • Встроенная поддержка source map (с помощью devtool: 'source-map' в конфигурации Webpack)

  • Горячая перезагрузка в процессе разработки и даже развёртывания (путём простого чтения обновлённого пакета и пересоздания экземпляра рендерера)

  • Внедрение критического CSS (при использовании *.vue файлов): автоматически встраивает CSS, необходимый компонентам во время рендеринга. Подробнее в разделе CSS.

  • Внедрение ресурсов с помощью clientManifest: автоматически добавляет оптимальные директивы preload и prefetch, а также фрагменты кода, необходимые для первоначального рендеринга.


Мы обсудим, как настроить Webpack для генерации необходимых частей для рендерера в следующем разделе, а сейчас давайте предположим, что у нас уже есть всё необходимое, и создадим рендерер:

Когда renderToString вызывается в рендерере, он автоматически выполнит функцию, экспортируемую сборкой для создания экземпляра приложения (передавая context в качестве аргумента), а затем рендерит его.

Обратите внимание, что рекомендуется установить опцию runInNewContext в значение false или 'once'. См. справочник API для подробностей.

Содержание. Начало работы · Bootstrap. Версия v4.0.0

Узнайте, что включено в Bootstrap, включая наши перекомпилированные данные и исходные коды. Помните, что для плагинов JavaScript Bootstrap’у требуется jQuery.



Предварительно компилированный Bootstrap



Строение скачанного архива BS4 будет таким:





bootstrap/
├── css/
│   ├── bootstrap.css
│   ├── bootstrap.css.map
│   ├── bootstrap.min.css
│   ├── bootstrap.min.css.map
│   ├── bootstrap-grid.css
│   ├── bootstrap-grid.css.map
│   ├── bootstrap-grid.min.css
│   ├── bootstrap-grid.min.css.map
│   ├── bootstrap-reboot.css
│   ├── bootstrap-reboot.css.map
│   ├── bootstrap-reboot.min.css
│   └── bootstrap-reboot.min.css.map
└── js/
    ├── bootstrap.bundle.js
    ├── bootstrap.bundle.min.js
    ├── bootstrap.js
    └── bootstrap.min.js

Это базовая форма Bootstrap: перекомпилированные файлы для быстрого подключения в почти любой веб-проект. Доступны: компилированные файлы CSS и JS (bootstrap.*), как и компилированные «облегченные» файлы (bootstrap.min.*). Карты исходного кода CSS (bootstrap.*.map) доступны для использования лишь с определенными инструментами разработчика в браузере. Связанные JS-файлы (bootstrap.bundle.js и минимизированный bootstrap.bundle.min.js) включают Popper, но не jQuery.

Кодовые карты дают независимый от языка способ показа соответствия рабочего кода и исходных кодов (sources), написанных вами при разработке.



Файлы СSS


Bootstrap включает несколько параметров для подключения всех ваших компилированных CSS.






CSS файлыРазметкаСодержаниеКомпонентыУтилиты

bootstrap.css

bootstrap.min.css

ВключеныВключеныВключеныВключены

bootstrap-grid.css

bootstrap-grid.min.css

Только Система сетокНе включеныНе включеныТолько flex утилиты

bootstrap-reboot.css

bootstrap-reboot.min.css

Не включеныТолько RebootНе включеныНе включены

Файлы JS


Аналогично имеются параметры для подключения всех или некоторых компилированных файлов JavaScript.





JS-файлыPopperjQuery

bootstrap.bundle.js

bootstrap.bundle.min.js

ВключеныНе включены

bootstrap.js

bootstrap.min.js

Не включеныНе включены

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


Загрузка исходного кода Bootstrap включает, наряду с исходниками Sass, CSS и JS, перекомпилированные механизмы публикации ресурсов CSS и JS.


Механизм публикации ресурсов (asset) полезен в следующих случаях:

  • При оформлении кода как расширения, ресурсы которого содержатся в той же папке, что и код.
  • При использовании ресурсов за корнем веб-сервера.
  • Для обработки ресурсов непосредственно перед публикацией. Например, сжатия CSS и JavaScript.
  • При использовании одного и того же ресурса множеством компонент (для исключения дубликатов).


Если быть более точным, сюда входит следующее:


bootstrap/
├── dist/
│   ├── css/
│   └── js/
├── docs/
│   └── examples/
├── js/
└── scss/

В папках scss/ и js/ лежат исходники нашего CSS и JS. Папка dist/ содержит всё перечисленное в параграфе Precompiled Bootstrap выше. Папка docs/ лежит исходный код документации, и содержит папку examples/ — примеры использования Bootstrap. Помимо этого, любой другой подключенный файл нужен для поддержки пакетов, содержит информацию о лицензии и разработке.



git — bundle.js кажется слишком большим для Github

У меня есть простое тестовое приложение React.js, которое я собрал, и я хотел бы разместить его на Github. Однако когда я упаковываю / компилирую приложение, размер файла bundle.js составляет ~ 4,5 МБ. И, очевидно, Github не разрешит обслуживать файлы такого размера для gh-pages.

Кто-нибудь знает максимальный размер файла, который я могу сделать bundle.js, чтобы он работал на Github?

Во-вторых, как я могу разделить bundle.js на меньшие размеры, чтобы он работал на Github?

1

ipatch

26 Мар 2017 в 22:07

2 ответа

Лучший ответ

Удаление devtool: "source-map" из webpack.config.js и создание отдельного файла конфигурации веб-пакета для производственных сборок сделали свое дело.

1

ipatch
27 Мар 2017 в 18:06

Очевидным решением было бы исключить папку, в которую ваш упаковщик выводит ваши пакеты JS, используя файл .gitignore.

Скорее всего, ваш .gitignore файл также содержит node_modules, так как вы не хотели бы, чтобы сотни библиотек и зависимостей, которые требуется для приложения реакции, были отправлены на github.

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

0

Alexander
27 Мар 2017 в 17:40

концепций | webpack

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

tip

Узнайте больше о модулях JavaScript и модулях webpack здесь.

Начиная с версии 4.0.0, webpack не требует файла конфигурации для объединения вашего проекта.Тем не менее, его невероятно легко настроить, чтобы он лучше соответствовал вашим потребностям.

Для начала вам нужно только понять его Core Concepts :

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

Для лучшего понимания идей, лежащих в основе сборщиков модулей, и того, как они работают внутри, обратитесь к этим ресурсам:

Запись

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

По умолчанию его значение — ./src/index.js , но вы можете указать другое (или несколько точек входа), установив свойство entry в конфигурации webpack. Например:

webpack.config.js

  module.exports = {
  запись: './path/to/my/entry/file.js',
};  
подсказка

Подробнее читайте в разделе «Точки входа».

Выходные данные

Свойство выходных данных сообщает webpack, где создавать пакеты , которые он создает, и как назвать эти файлы. По умолчанию это ./dist/main.js для основного выходного файла и папка ./dist для любого другого сгенерированного файла.

Вы можете настроить эту часть процесса, указав поле output в вашей конфигурации:

webpack.config.js

  const path = require ('path');

модуль.экспорт = {
  запись: './path/to/my/entry/file.js',
  выход: {
    путь: path.resolve (__ dirname, 'dist'),
    имя файла: 'my-first-webpack.bundle.js',
  },
};  

В приведенном выше примере мы используем свойства output.filename и output.path , чтобы сообщить webpack имя нашего пакета и куда мы хотим его отправить. Если вам интересно, какой модуль пути импортируется вверху, это основной модуль Node.js, который используется для управления путями к файлам.

tip

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

Загрузчики

По умолчанию webpack понимает только файлы JavaScript и JSON. Загрузчики позволяют webpack обрабатывать другие типы файлов и преобразовывать их в допустимые модули, которые могут быть использованы вашим приложением и добавлены в граф зависимостей.

предупреждение

Обратите внимание, что возможность импортировать любого типа модуля, например.грамм. .css файлов — это особенность веб-пакета, которая может не поддерживаться другими сборщиками или программами запуска задач. Мы считаем, что это расширение языка оправдано, поскольку оно позволяет разработчикам построить более точный граф зависимостей.

На высоком уровне загрузчики имеют два свойства в конфигурации вашего веб-пакета:

  1. Свойство test определяет, какой файл или файлы следует преобразовать.
  2. Использование Свойство указывает, какой загрузчик следует использовать для преобразования.

webpack.config.js

  const path = require ('path');

module.exports = {
  выход: {
    имя файла: 'my-first-webpack.bundle.js',
  },
  модуль: {
    правила: [{test: /\.txt$/, используйте: 'raw-loader'}],
  },
};  

В приведенной выше конфигурации определено свойство rules для одного модуля с двумя обязательными свойствами: test и use . Это сообщает компилятору webpack следующее:

«Привет, компилятор webpack, когда вы встречаете путь, который разрешается в ‘.txt ‘внутри оператора require () / import , используйте raw-loader , чтобы преобразовать его перед добавлением в пакет ».

warning

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

warning

Имейте в виду, что при использовании regex для сопоставления файлов вы не можете его цитировать.т.е. /\.txt$/ — это не то же самое, что '/\.txt$/' или "/\.txt$/" . Первый инструктирует webpack сопоставлять любой файл, который заканчивается на .txt, а второй инструктирует webpack сопоставлять одиночный файл с абсолютным путем ‘.txt’; это скорее всего не ваше намерение.

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

Плагины

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

tip

Узнайте об интерфейсе плагина и о том, как его использовать для расширения возможностей webpack.

Чтобы использовать плагин, вам нужно require () его и добавить в массив plugins . Большинство плагинов можно настроить с помощью параметров. Поскольку вы можете использовать плагин несколько раз в конфигурации для разных целей, вам необходимо создать его экземпляр, вызвав его с помощью оператора new .

webpack.config.js

  const HtmlWebpackPlugin = require ('html-webpack-plugin');
const webpack = require ('webpack');

модуль.экспорт = {
  модуль: {
    правила: [{test: /\.txt$/, используйте: 'raw-loader'}],
  },
  плагины: [новый HtmlWebpackPlugin ({template: './src/index.html'})],
};  

В приведенном выше примере html-webpack-plugin генерирует HTML-файл для вашего приложения, автоматически внедряя все ваши сгенерированные пакеты.

подсказка

Есть много плагинов, которые webpack предоставляет из коробки! Ознакомьтесь со списком плагинов.

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

Mode

Установив для параметра mode значение development , production или none , вы можете включить встроенные оптимизации webpack, соответствующие каждой среде. Значение по умолчанию — , производство .

  module.exports = {
  режим: 'производство',
};  

Подробнее о конфигурации режима и оптимизации каждого значения.

Совместимость с браузером

webpack поддерживает все браузеры, совместимые с ES5 (IE8 и ниже не поддерживаются). webpack требуется Promise для импорта () и require.ensure () . Если вы хотите поддерживать старые браузеры, вам нужно будет загрузить полифилл перед использованием этих выражений.

Среда

webpack 5 работает на Node.js версии 10.13.0+.

К v4 с v3 | webpack

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

Node.js v4

Если вы все еще используете Node.js v4 или ниже, вам необходимо обновить установку Node.js до Node.js v6 или выше.

Инструкции по обновлению версии Node.js можно найти здесь.

CLI

Интерфейс командной строки перемещен в отдельный пакет: webpack-cli. Вам необходимо установить его перед использованием webpack, см. Базовую настройку.

Руководство по установке можно найти здесь.

Обновить плагины

Многие сторонние плагины необходимо обновить до последних версий, чтобы они были совместимы с webpack 4.Ссылки на популярные плагины можно найти здесь.

mode

Добавьте новую опцию mode в вашу конфигурацию. Установите для него значение «производство» , «разработка» или «нет» в зависимости от типа конфигурации.

webpack.config.js

  module.exports = {
  // ...
+ режим: 'производство',
}  
подсказка

Цели «разработка» режима и «производство» режима различаются.Вы можете использовать webpack-merge , как показано в производственном руководстве, для оптимизации конфигураций.

Устаревшие / удаленные плагины

Эти плагины можно удалить из конфигурации, поскольку они используются по умолчанию в производственном режиме:

webpack.config.js

  module.exports = {
  // ...
  плагины: [
- новый NoEmitOnErrorsPlugin (),
- новый ModuleConcatenationPlugin (),
- новый DefinePlugin ({"process.env.NODE_ENV": JSON.stringify ("production")})
- новый UglifyJsPlugin ()
  ],
}  

Эти плагины используются по умолчанию в режиме разработки

webpack.config.js

  module.exports = {
  // ...
  плагины: [
- новый NamedModulesPlugin ()
  ],
}  

Эти плагины устарели и теперь удалены:

webpack.config.js

  module.exports = {
  // ...
  плагины: [
- новый NoErrorsPlugin (),
- новый NewWatchingPlugin ()
  ],
}  

CommonsChunkPlugin

Был удален CommonsChunkPlugin . Вместо этого можно использовать параметры optimisation.splitChunks .

Подробнее см. Документацию по оптимизации .splitChunks . Конфигурация по умолчанию может уже соответствовать вашим потребностям.

tip

При генерации HTML из статистики вы можете использовать optimisation.splitChunks.chunks: "all" , что в большинстве случаев является оптимальной конфигурацией.

import () и CommonJS

При использовании import () для загрузки не-ESM результат изменился в webpack 4. Теперь вам нужно получить доступ к свойству по умолчанию , чтобы получить значение модуля .экспорт .

non-esm.js

  module.exports = {
  sayHello: () => {
    console.log ('привет, мир');
  },
};  

example.js

  function sayHello () {
  import ('./ non-esm.js'). then ((module) => {
    module.default.sayHello ();
  });
}  

json и загрузчики

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

webpack.config.js

  module.exports = {
  // ...
  правила: [
    {
      тест: /config\.json$/,
      погрузчик: 'спецпогрузчик',
+ введите: 'javascript / auto',
      параметры: {...}
    }
  ]
};  

При использовании json-loader его можно удалить:

webpack.config.js

  module.exports = {
  // ...
  правила: [
    {
- тест: /\.json$/,
- загрузчик: 'json-loader'
    }
  ]
};  

модуль.loaders

module.loaders устарели с webpack 2 и теперь удалены в пользу module.rules .

Установка | webpack

В этом руководстве рассматриваются различные методы, используемые для установки webpack.

Предварительные требования

Прежде чем мы начнем, убедитесь, что у вас установлена ​​свежая версия Node.js. Текущая версия долгосрочной поддержки (LTS) — идеальная отправная точка. Вы можете столкнуться с множеством проблем со старыми версиями, поскольку в них может отсутствовать функциональность, необходимая для веб-пакета и / или связанных с ним пакетов.

Локальная установка

Последний выпуск webpack:

Чтобы установить последний выпуск или конкретную версию, выполните одну из следующих команд:

  npm install --save-dev webpack

npm install --save-dev webpack @   
tip

Использовать ли --save-dev или нет, зависит от ваших вариантов использования. Допустим, вы используете веб-пакет только для объединения, тогда рекомендуется установить его с опцией --save-dev , поскольку вы не собираетесь включать веб-пакет в свою производственную сборку.В противном случае вы можете игнорировать --save-dev .

Если вы используете webpack v4 или новее и хотите вызвать webpack из командной строки, вам также потребуется установить интерфейс командной строки.

  npm install --save-dev webpack-cli  

Локальная установка — это то, что мы рекомендуем для большинства проектов. Это упрощает индивидуальное обновление проектов при внесении критических изменений. Обычно webpack запускается через один или несколько сценариев npm, которые будут искать установку webpack в вашем локальном каталоге node_modules :

  "scripts": {
  "build": "webpack --config webpack.config.js "
}  
tip

Чтобы запустить локальную установку webpack, вы можете получить доступ к его бинарной версии как node_modules / .bin / webpack . В качестве альтернативы, если вы используете npm v5.2.0 или выше, вы можете запустить npx webpack для этого.

Глобальная установка

Следующая установка NPM сделает webpack доступным глобально:

  npm install --global webpack  
warning

Обратите внимание, что это не рекомендуется .Глобальная установка привязывает вас к определенной версии webpack и может завершиться ошибкой в ​​проектах, использующих другую версию.

Bleeding Edge

Если вы с энтузиазмом относитесь к использованию последних версий webpack, вы можете установить бета-версии или даже прямо из репозитория webpack, используя следующие команды:

  npm install --save-dev webpack @ next

npm install --save-dev webpack / webpack  
warning

Будьте осторожны при установке этих новейших выпусков! Они все еще могут содержать ошибки и поэтому не должны использоваться в производственной среде.

javascript — Зачем и где вообще нам нужен bundle.js?

Откуда берется комплектация?

Мы начали объединять наши активы в пакеты из соображений производительности.

  • HTTP1 поддерживает ограниченное количество запросов в одном соединении. Создание соединений для каждого актива убивало производительность.
  • Мы начали объединять вещи постранично, чтобы повысить производительность за счет более эффективного кэширования.
  • Нам удалось добавить к нему отпечаток пальца и загрузить его в CDN.(домашняя страница.231434.js). Итак, мы смогли развернуть наше приложение, добавив его в докер.
  • Bundling также помогает нам еще больше уменьшить размер страницы, потому что сборщик знает всю систему. Это означает, что он может удалить неиспользуемые вещи и упростить минимизацию. Вы не можете обойтись без сборщика пакетов.
  • Также упаковщики используют транспилеры. Браузеры не всегда могут запускать коды, которые мы пишем, например, Typescript, CoffeeScript. Составители пакетов могут легко преобразовывать эти коды в пакеты.

Он нам еще нужен?

В настоящее время многое меняется, как мы объединяем наши активы.

  • Во-первых, почти все браузеры теперь поддерживают HTTP / 2. Таким образом, мы можем запросить несколько файлов по одному и тому же соединению. Объединение из-за этого больше не требуется. Также у нас есть HTTP / 2 server push.
  • Библиотеки

  • , такие как React, Angular, Vue, намного эффективнее по размеру. Их можно легко загрузить на страницу из источника, поддерживающего gzip.

Это причины, по которым нам больше не нужна комплектация.

Но, исходя из вашего проекта, нам может понадобиться комплектация.Это настоящая правда.

Я бы еще пошел с комплектацией.


В моей компании мы используем систему оркестровки контейнеров для управления нашими докеризованными приложениями. Мы можем запустить несколько версий одновременно. Создание отпечатков пальцев для файлов при их объединении и загрузке в CDN по-прежнему более эффективно для нас. А также мы пытаемся использовать предварительную выборку и предварительную загрузку. CDN помогает нам сократить время загрузки посетителей из других стран.
А также мы получаем поддержку от обслуживающего персонала, чтобы изменить активы, когда нам это нужно, по страницам.

Так что в настоящее время он основан только на вашем проекте. Больше нет причин для производительности.

Понимание концепции комплектации для начинающих | Афинья Дечалерт | hashmap

Это намного проще, чем вы думаете

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

Вот здесь и вступает в игру объединение. Инструменты объединения, такие как Webpack и Browsify, организуют и помещают весь ваш JavaScript, HTML, CSS, изображения и все остальное в несколько аккуратных небольших файлов, чтобы ваше веб-приложение работало бесперебойно. Эти инструменты связывания уже встроены в интерфейсы командной строки Angular и React.

JavaScript вышел с возможностью использования модулей еще в ES6. Однако браузерам потребовалось немного времени, чтобы наверстать упущенное. Например, Chrome реализовал поддержку в середине 2017 года, через два года после того, как модули были впервые выпущены как языковая функция.Иногда может показаться, что технологии развиваются быстро, но иногда скорость адаптации может быть медленной.

Но прежде чем мы продолжим, что такое модули?

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

Однако при импорте возникает другая проблема. В обычных условиях JavaScript часто используется во внешнем интерфейсе вместе с HTML и CSS. Это означает, что если вы хотите запустить свой код, вам понадобится набор тегов скрипта. Следующее, что вы знаете, — вся ваша страница завалена всеми написанными вами крошечными модулями. Становится хуже, когда вы начинаете добавлять библиотеки, у которых есть свои зависимости. Теперь представьте, что вам нужно выяснить, какой из них нужен, а какой нет, и в каком контексте рендеринга.

Все может запутаться очень быстро.

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

Нет собственного способа «построить» приложение JavaScript. Это не похоже на C ++ или Java, где вам нужно скомпилировать программу, чтобы она работала. Суть JavaScript в том, что он запускается в браузере «на лету» — эффективность не является частью исходного уравнения.

«Создание» приложения JavaScript больше связано с минимизацией текущего приложения и созданием оптимизированного вывода. Его не заботит удобочитаемость или понимание человеком, сокращение ваших значений и переменных там, где это возможно. Инструменты объединения, такие как Webpack, просто переупаковывают ECMAScript в форму, которая намного эффективнее с точки зрения конечного созданного файла. Ваша верная консоль часто является порталом для выполнения этого фантастического акта расчетливой магии.

Пакет — это результат процесса, который объединяет все в несколько (если не один) файлов наиболее оптимизированным образом.

У каждого инструмента связывания есть свой метод уплотнения вещей в симпатичную небольшую «связку». Webpack — это инструмент, который встроен в проекты, созданные Angular CLI, и действует как инструмент, который помещает все ваши ресурсы — JavaScript, изображения, шрифты, CSS и все остальное, что вы можете придумать, в нечто, называемое графом зависимостей.

Раньше мы сохраняли все наши зависимости JavaScript, включая их через теги сценария на нашей HTML-странице. Эти теги скрипта также должны быть в определенном порядке, иначе приложение не будет работать.

Если вы имели удовольствие писать код в начале 2000-х, следующие «включает» должны показаться вам знакомыми.

  







Для каждого файла требуется отдельный HTTP-запрос, то есть 5 запросов туда и обратно, чтобы ваше приложение было запущено. Поэтому было бы лучше, если бы вы могли объединить все 5 файлов в 1:

  
  
  

(Хотя с [HTTP / 2] (https://developers.google.com/web/fundamentals/performance/http2/), сейчас это гораздо менее актуально)

Так как же нам создать dist / bundle.js ?

В процессе возникает несколько проблем:

  • Как нам поддерживать порядок "файлов", которые должны быть включены?
    • Было бы здорово, если бы между "файлами" был какой-то порядок зависимости
  • Как предотвратить конфликты имен между «файлами»?
  • Как определить неиспользуемый «файл» в пакете?

Все это можно решить, если мы знаем отношения между каждым файлом, например:

  • Какой файл зависит от другого?
  • Какой интерфейс предоставляется из файла? и
  • Какие открытые интерфейсы используются другим?

Эта информация, предоставленная, может решить поставленные проблемы соответственно.Итак, нам нужен декларативный метод для описания отношений между файлами, который привел нас к модульной системе JavaScript.

Модули

CommonJS или ES6 предоставляют нам возможность указать, от каких файлов мы зависим и какой из их интерфейсов мы используем в нашем файле.

 
const foo = require ('./ foo');
module.exports = бар;


импортировать foo из './foo';
панель экспорта по умолчанию;  

На основе информации, собранной из модульной системы, как нам связать файлы вместе и сгенерировать файл пакета, который инкапсулирует все?

Если вы внимательно изучите пакет, сгенерированный webpack и rollup, вы заметите, что 2 самых популярных пакетировщика используют совершенно другой подход к объединению, и здесь я их придумал: "webpack way" и "rollup. путь " .

Проиллюстрируем это на примере:

Допустим, у вас есть 3 файла: circle.js , square.js и app.js :

 
const PI = 3,141;
область функции экспорта по умолчанию (радиус) {
  вернуть ПИ * радиус * радиус;
}  
 
область функции экспорта по умолчанию (сбоку) {
  обратная сторона * сторона;
}  
 
импортировать squareArea из './square';
импортировать circleArea из './circle';
console.log ('Площадь квадрата:', squareArea (5));
приставка.log ('Площадь круга', circleArea (5));  

"Путь через webpack"

Как бы выглядел комплект "webpack way"?

 
const modules = {
  'circle.js': function (exports, require) {
    const PI = 3,141;
    export.default = функциональная область (радиус) {
      вернуть ПИ * радиус * радиус;
    }
  },
  'square.js': function (exports, require) {
    export.default = функциональная область (сбоку) {
      обратная сторона * сторона;
    }
  },
  'app.js': function (exports, require) {
    const squareArea = require ('square.js '). по умолчанию;
    const circleArea = require ('circle.js'). по умолчанию;
    console.log ('Площадь квадрата:', squareArea (5))
    console.log ('Площадь круга', circleArea (5))
  }
}

webpackStart ({
  модули,
  запись: 'app.js'
});  

Я сделал небольшие изменения для упрощения иллюстрации

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

Во-вторых, каждый модуль обернут функцией . Функция имитирует область видимости модуля, в которой все, что объявлено в модуле, ограничено внутри себя. Сама функция называется «фабричной функцией модуля». Как видите, он принимает несколько параметров, позволяющих модулю экспортировать свой интерфейс, а также требовать от других модулей.

В-третьих, приложение запускается через webpackStart , что является функцией, которая склеивает все вместе .Сама функция, часто называемая «среда выполнения» , является наиболее важной частью пакета. Он использует «карту модулей» и модуль ввода для запуска приложения.

 

функция webpackStart ({модули, запись}) {
  const moduleCache = {};
  const require = moduleName => {
    
    if (moduleCache [имя_модуля]) {
      return moduleCache [имя_модуля];
    }
    const exports = {};
    
    
    moduleCache [имя модуля] = экспорт;

    
    
    модули [имя_модуля] (экспорт, требуется);
    return moduleCache [имя_модуля];
  };

  
  требовать (запись);
}  

Я сделал небольшие изменения для упрощения иллюстрации

webpackStart определяет 2 вещи: функцию "require" и кеш модуля.Функция «require» отличается от функции , которая требует от CommonJS. "require" принимает имя модуля и возвращает экспортированный интерфейс из модуля, например: для circle.js это будет {default: function area (radius) {...}} . Экспортированный интерфейс кэшируется в кеш-памяти модуля, поэтому, если мы многократно вызываем "require" для одного и того же имени модуля, "фабричная функция модуля" будет выполнена только один раз.

С определением "require" запуск приложения будет просто "требовать" модуля ввода.

"Путь свертки"

Теперь вы увидели, как выглядит пакет webpack, давайте взглянем на пакет "rollup way":

 
const PI = 3,141;

функция circle $ area (radius) {
  вернуть ПИ * радиус * радиус;
}

function square $ area (side) {
  обратная сторона * сторона;
}

console.log ('Площадь квадрата:', квадрат $ area (5));
console.log ('Площадь круга', круг $ area (5));  

Я сделал небольшие изменения для упрощения иллюстрации

Во-первых, ключевое отличие накопительного пакета заключается в том, что он намного меньше по сравнению с пакетом веб-пакета.Нет карты модулей , по сравнению с "способом webpack". Все модули «сплющивают» в связку . Нет функции обертывания модулей. Все переменные / функции, которые были объявлены в модуле, теперь объявлены в глобальной области.

Если все, что объявлено в области отдельного модуля, теперь объявлено в глобальной области, что произойдет, если 2 модуля объявят переменную / функцию с тем же именем?

Итак, свертка переименует имя переменной / функции в , так что конфликта имен не произойдет.В нашем примере и circle.js , и square.js объявили function area () {} в модуле, при объединении вы видите, что обе функции и их использование были переименованы, чтобы избежать конфликтов.

Одним из побочных эффектов отсутствия упаковки модуля в функцию является поведение eval , см. Здесь для более подробного объяснения

Во-вторых, порядок модулей в комплекте имеет значение .Что ж, вы можете возразить, что круг $ площадь и квадрат $ площадь могут идти после console.log , и он все равно будет работать, но PI должен быть объявлен до console.log из-за временной остановки зона. Таким образом, сортировка модулей в порядке их зависимости имеет значение для «сводного пути».

В целом, «метод накопления» оказался лучше, чем «способ веб-пакета». Он имеет меньший пакет и меньше накладных расходов во время выполнения за счет удаления всех функций.

Есть ли недостаток у "rollup way"?

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

 
const circle = require ('./ circle');

module.exports.PI = 3.141;

console.log (круг (5));  
 
const PI = require ('./ shape');
const _PI = PI * 1
module.exports = function (radius) {
  вернуть _PI * radius * radius;
}  

Я сделал небольшие изменения для упрощения иллюстрации

В этом примере фигура .js зависит от circle.js и circle.js зависит от shape.js . Итак, для объединения, чтобы определить, какой модуль должен быть первым, а какой другой в выходном пакете, для него не существует "правильного" ответа. Либо circle.js , затем shape.js или shape.js , затем circle.js . Итак, вы могли бы получить следующий выходной пакет:

 

const _PI = PI * 1;
функция circle $ Area (radius) {
  вернуть _PI * radius * radius;
}


const PI = 3.141;
console.log (обведите $ Area (5));  

Вы можете сказать, что это будет проблематично, не так ли?

Есть решение для этого? Короткий ответ - нет .

«Простое» исправление - не использовать циклическую зависимость. Rollup выдаст вам предупреждений, если они встретятся.

Что ж, пример "работает" благодаря тому, что у нас есть операторы, которые немедленно оцениваются в модуле. Если поменять оценку _PI на ленивую:

 
const PI = require ('./форма');
const _PI = () => PI * 1;
module.exports = function (radius) {
  return _PI () * радиус * радиус;
}  

порядок модулей сейчас особого значения не имеет:

 

const _PI = () => PI * 1;
функция circle $ Area (radius) {
  return _PI () * радиус * радиус;
}


const PI = 3,141;
console.log (обведите $ Area (5));  

Это связано с тем, что на момент оценки _PI уже было определено PI .

Итак, подведем итог тому, что мы узнали на данный момент:

  • Сборщик модулей помог нам объединить несколько модулей JavaScript в 1 файл JavaScript.
  • Различные пакеты пакетов по-разному, и мы рассмотрели 2 из современных пакетов, webpack и rollup
  • "путь веб-пакета":
    • использует карту модулей
    • использует функцию для обертывания каждого модуля
    • имеет код времени выполнения, который склеивает модуль вместе
  • "сводный путь":
    • более плоский и меньший комплект
    • не использует функцию обертывания модуля
    • порядок имеет значение, требуется сортировка на основе зависимости
    • круговая зависимость может не работать

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *