Модули JavaScript

[Aetet]

А почему не webpack? Он аналогично поддерживает AMD плюс CommonJS, нарезание файлов на чанки, быстрее пересборка, чем r.js. Ну а плагинами вообще доруливается все что угодно. Хоть сборка стилей на проекте.

[MCBumf]

На сколько я помню, в webpack нет возможности загружать модули по требованию, это только сборщик модулей (module bundler), а не загрузчик модулей (module loader), как requirejs. В статье описано несколько кейсов, когда динамическая загрузка модулей очень полезна.

[Aetet]

Динамический require (загрузка по требованию) в webpack все-таки есть.
webpack.github.io/docs/code-splitting.html#defining-a-split-point

Если же вы хотите загрузить целый бандл, то это решается через loaders:
github.com/webpack/bundle-loader

[serf]

В нативных ES6 модулях можно ли так организовать сборку чтобы было разденение как миниумум на 2 итоговых JS файла, один для кода приложения и один для библиотек? То есть код приложения ведь в любом случае будет ссылаться на библиотечный функицонал (импортировать), но при этом помещать библиотеки внутрь итогового JS файла приложения не нужно. При этом пречислять все модули для склеивания в один файл не хочется, нужно чтобы сборщик сам построил дерево зависимостей и собрал в один файл. Такая возможность есть при использовании browserify (опция/метод external).

[VasilioRuzanni]

Еще как можно.

[serf]

Это не совсем то, насколько я понял таким образом в shared-bundle.js будут пересекающиеся модули (используемые и в first и в second деревьях), а нужно чтобы в shared-bundle.js были только библиотеки third-party/vendor (явное указание). Но плагаю что средства есть и для этого, просто я не сталкивался с ними, и хотел сразу узнать по опыту бывалых, без гугления.

[Aetet]

github.com/webpack/docs/wiki/list-of-plugins#commonschunkplugin
ES6-модули грузятся через бабель, сборку осуществляет webpack/

[VasilioRuzanni]

Вебпак хорош функциональностью, но очень уж у него раздутый (многословный) код конфигурации. Я сам перепробовав вообще все, что было, на System.js остановился из за простоты и из за того, что его API работы с модулями — это, по сути, полифилл будущей нативной реализации браузерами.

[VasilioRuzanni]

Совершенно верно, и с помощью System.js и Webpack можно достичь желаемого. Тут нужно пробовать, конечно.

С помощью SystemJS Builder можно, например:

// Отдельно построить vendor-бандл
builder.build('third-party/vendor/**/*', 'shared-bundle.js', { minify: true, sourceMaps: true });

// И исключить модули shared-bundle.js из app.js
builder.build('app/**/* - shared-bundle', 'app.js', { minify: true, sourceMaps: true });

[Arilas]

В Browserify можно, я дроблю так:

var dependencies = [
    'react',
    'react-router',
    'react-bootstrap',
    'react-router-bootstrap',
    'moment'
];
var watcher  = browserify({
        entries: [path.ENTRY_POINT],
        debug: options.development,
        cache: {}, packageCache: {}, fullPaths: false
    });
    watcher.external(dependencies);
//....
var vendorsBundler = browserify({
        debug: options.development,
        require: dependencies
    });
/....

То-есть я в одном говорю, что они внешние, в другом говорю, что подключи только их.

[serf]

Я выше писал что в Browserify можно, отсюда вопрос и возник можно ли не в Browserify.

[VasilioRuzanni]

r.js берет на себя слишком многое, поэтому плохо интегрируется, к примеру, в gulp.js.

Да и вообще — зачем использовать require.js, когда у нас давно есть SystemJS (и SystemJS Builder), которые совершенно прозрачно и без лишних усилий «умеют» все модули, включая ES6 (через Babel, Traceur или TypeScript)?

[ianbrode]

Кроме интеграции у r.js есть другой недостаток — он не режет require/define. Придётся либо тащить сам require на клиент, либо заменять на что-то минималистичное типа almond.js. Есть вариант дописать скрипт который при сборке будет резать эти функции. В старом jquery 1.11 такую штуку реализовали для сборки. Если любопытно, можно посмотреть тут: github.com/jquery/jquery/blob/1.11-stable/build/tasks/build.js.

[VasilioRuzanni]

Ну как по мне — «компиляция» в AMD и какой-нибудь минималистичный define/require — вполне себе вариант за неимением альтернативы. Я, напротив, обычно вижу необходимость добавлять всяческие define-обертки (например, над js-файлами, написанными как CommonJS-модули), а не обрезать их (иначе зачем их тогда вообще писать?).

[Zenitchik]

Бывают обёртки, обеспечивающие линковку в девелопе. При билде их целесообразно выпилить вместе с линковшиком.
StealJS — типичный представитель. Билдер в итоге написали свой.

[arusakov]

Отличная сравнительная таблица webpack.github.io/docs/comparison.html показывает, что и какой сборщик модулей умеет. Особенно впечатляет параметр Runtime overhead у webpack.

[vba]

Если я не ошибаюсь, то по тестируемости веб приложений, подход AMD уступает CommonJS. AMD приходится тестировать в браузере или при помощи phantomjs тогда как CommonJS можно тестировать как обычные node.js модули.

[Large]

Вот еще не слишком популярная, но рабочая библиотека для commonjs модулей, умеет подгружать модули синхронно и асинхронно.

[YakovLitvin]

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