r.js, browserserify, но jossy объективно лучше

ES6 modules + traceur. сделают из кусков\файлов отдельные модули

и ещё эти модули нужно загрузить - можно по отдельности, можно сшить их все в один файл и грузануть

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

пользовался им когда-то, но в итоге перебрался на grunt

Гм, тут же речь идёт о предварительной статичной сборке, а ES6 модули это сахарный AMD же.

Для условной статичной сборки проекта удобней jossy я не встречал, но может конечно плохо искал :)

Вот как раз Jossy это делает оч хорошо, там можно ставить зависимости и метки.

быстро же ты ответил :)

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

На колбеке:)

Что имеешь ввиду под "сшивать те, которые вызваны"?

Вот пример: https://github.com/kobezzza/Collecti...ter/builds.es6

Я могу закомментировать например строчку 'single.add': true, но для 'mult.addOrSet': true также нужен add, и Jossy про это знает и поэтому сможет удалить из сборки 'single.add' только тогда, когда на него перестанут ссылаться другие модули.

компоновка\оптимизация. у requirejs есть такая штука

к примеру , у меня есть модули HelloWorld, Unused и файл app.js, где используется модуль HelloWorld, а Unused не используется.

при компоновке всего в один файл там должно быть содержимое файла app.js и модуля HelloWorld, а содержимое Unused записываться туда не должно

только вот не хочется использовать requirejs, а хочется использовать ES6 modules. как этого достичь, я пока не придумал... у гранта есть таск, где можно формировать список файлов с помощью функции и делегировать выполнение другому таску, но есть ещё вопрос - как отыскать зависимости то?

для компоновки фич библиотеки выглядит очень удобно, но если есть проект в продакшене, за зависимостями человеку лучше вообще не следить. по крайней мере, мне это трудно делать :) а вот когда модуль сам говорит, от чего он зависит, так легче

такая же идея ("модуль говорит, от чего он зависит") у пакетов в линуксовых менеджерах пакетов. и у пакетов npm тоже

Теперь понял о чём ты :) Да, не удобно. Я юзаю файлы манифесты, как npm и похожих штук, например:

// blocks/b-avatar-uploader-form/b-avatar-uploader-form.json

{
	"block": "b-avatar-uploader-form",
	"extends": "b-window",

	"use": {
		"logic": true, // js
		"style": true, // stylus
		"tpl": true // snakeskin
	},

	"dependencies": [
		"b-form",
		"b-image-editor",
		"b-progress",
		"b-uploader",
		"b-button"
	]
}

И такой подход для всего: виджеты, страницы, сборки (т.е. одна сборка зависит от другой или наследуется). Сборщик сам бьёт на модули, выкидывает дубликаты и т.д. по построенному графу, использую своё решение интегрированное как плагин для Grunt.

Кое-что удалось нагуглить: PR 1089. Походу, этого пока просто нет и работа в прогрессе. Хм, может помочь)

вот то же для Gulp: PR 19

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

Еще не юзал, но хочу, есть ли какие то хорошие фолбеки?

Все тупо сшивать тоже вариант, но не хочется его юзать.

Спасибо попробую.
Да не получается нормально скомпилить если вызывать из скрипта.

прямо сейчас я занят этим. как закончу, поделюсь :)я уже обошел это дело! сшивает всё в один файл requirejs, но он не сшивает SourceMap от traceur.

в общем, ещё есть проблемы :)