Requirejs vs browserify vs webpack для заказа загрузки js: я просто перемещаю ситуацию с одной стороны на другую?

Хорошо, это 2016. Webpack выглядит победителем requirejs и browserify. Я читал об этих трех технологиях, чтобы решить очень специфическую проблему. Я хочу избежать этого в своем HTML файле (часть приложения AngularJS)

<script src="some-file.js"></script>
<script src="some-file2.js"></script>
<script src="some-file3.js"></script>
<!-- Dozens of similar lines here... -->

Конечно, порядок этих строк в моем файле HTML имеет значение. Bootstrap будет запрашивать jQuery и т.д.

Первое, что я нашел: requirejs. Вы просто указываете что-то вроде этого:

<script src="my-bundled-file.js"></script>

И тогда вы решаете проблему зависимости с JS. Идя дальше, я нашел здесь 2 подхода:

  • CommonJS (браузер)
  • AMD (require.js)

Webpack работает с обоими подходами, что звучит неплохо.

В конце 3 инструментария могут использоваться для одного и того же: объединить несколько файлов только в один. Но меня беспокоит порядок, в котором эти файлы связаны.

Я не хочу заботиться об этом и, похоже, использует эти решения (или даже gulp + gulp -concat, как это предлагается здесь), Я просто перемещаю проблему: теперь я указываю модули, которые мое приложение использует с JS-кодом, но мне все равно нужно поместить модули в правильном порядке, даже с помощью WebPack (пример здесь: звонки require должны быть в правильном порядке)

Итак, мои вопросы:

  • Я не понимаю эти инструменты? Я просто хочу решить проблему с загрузкой и выглядит так, как будто я этого не делаю
  • Эти инструменты решают другую проблему (отсутствие встроенных модулей в ES5, которые приводят к загрязнению глобальной области)?

Ответы

Ответ 1

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

Думаю, да. С CommonJS и инструментами, которые связывают его с порядком загрузки, в значительной степени становится неактуальным, что вам не нужно управлять. Вы просто require(), что вам нужно, где вам это нужно. Есть некоторые случаи, когда они по-прежнему актуальны, но в основном связаны с такими вещами, как глобальные побочные эффекты и круговые зависимости. Использование CommonJS и связывания полностью отличается от конкатенации ряда скриптов.

эти инструменты решают другую проблему (отсутствие встроенных модулей в ES5, которые приводят к загрязнению глобальной области)?

Модульная система CommonJS предназначена для устранения нехватки встроенных модулей в JavaScript, а версия ее используется в Node. Заголовок в Browserify - это "пакеты для node для браузера", хотя на практике он также используется для создания пакетов для запуска в node и для комплектации модулей, предназначенных только для работы в браузере.

В node пакеты не нужны, поскольку node обертывает исполняемый код и предоставляет реализацию для его семантики модуля. Чтобы запускать модули с использованием этой системы в браузерах, вам нужно связать ее, потому что браузер не обертывает код, чтобы предоставить ему то, что составляет интерфейс модуля, например require(), module, exports. Эта часть того, что делает пакет для вас: обертывает код для обеспечения этого интерфейса.

Другое дело, что он делает для вас, который решает ваш вопрос о заказе, рекурсивно обнаруживает зависимости. Так, как я уже сказал, вы require(), что вам нужно, где вам это нужно, и наведите указатель на запись script. Компилятор проанализирует script, чтобы найти любой require() и включить модули, которые они ссылаются в комплекте. Он повторит, что для этих модулей до бесконечности.

Думаю, вы найдете намного больше удовольствия от CommonJS по сравнению с AMD, но я бы сказал, что это далеко не однозначная победа для Webpack за Browserify. Оба популярны. Browserify широко используется, в том числе для создания частей проектов, таких как Babel и React.

Моим советом было бы начать с Node -строчных модулей CommonJS и Browserify (примечание: я являюсь хранителем Browserify).

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