Closed Kuznetsov-Ilia closed 10 years ago
Привет.
Все пути в том числе вывод файла строится относительно файла конфига. %lmd_config_dir% + %root% + .. = project/.lmd/ + ../js + ../output.js
. Приложи, пожалуйста, конфиг или его часть в котором проблемы.
autogenerated.bundle.js:
module.exports = {
name: 'page-contacts',
root: '../../../src',
modules: {
'bundle-contacts': '@page-contacts.js?<%= build_id %>'
},
bundles: {
contacts: {
modules: {
'page-contacts': 'pages/page-contacts/view.js',
'page-contacts-template': 'pages/page-contacts/autogenerated.index.template.js',
'page-contacts-css' : '@/css/page-contacts.css',
'form' : 'blocks/form/view.js'
}
}
},
shortcuts: true,
output : '../public/js/page-contacts.js'
}
output:
[gulp] Using file /Users/ikuznecov/projects/{projectname}/gulpfile.js
[gulp] Working directory changed to /Users/ikuznecov/projects/{projectname}
[gulp] Running 'lmd-pages-bundles'...
info: Building `autogenerated.bundle.js` (.lmd/autogenerated.bundle.js.lmd.js(on))
warn: Some of your modules are declared but not used:
warn: - bundle-contacts
warn: - page-contacts
warn: - page-contacts-template
warn: - page-contacts-css
warn: - form
warn:
info: Writing LMD Package to /Users/ikuznecov/public/js/page-contacts.js
info: Writing LMD Bundle contacts to /Users/ikuznecov/public/js/page-contacts.contacts.js
events.js:72
throw er; // Unhandled 'error' event
^
Error: ENOENT, open '/Users/ikuznecov/public/js/page-contacts.js'
Немного разовью тему как я дошёл до жизни такой... У меня есть потребность генерить на каждую страницу свой бандл по конфигу который будет генериться сам по себе сторонними средствами - т.е. в главном конфиге мне надо как-то занклюдить по маске такие конфиги типа
bundles: 'pages/*/autogenerated.bundle.json'
при этом сопоставить внешний файлик можно только именованному ключу в bundles, а не самому ключу bundles, экспериментирую пока с другими ключами типа depends, но выходит плохо, можешь подсказать как это правильно приготовить не выходя за рамки lmd конфигов?
Попробуй еще запустить "dry-run" lmd info autogenerated.bundle
. Кстати, почему не подходят различные сборки (несколько конфигов) по одной на каждую страницу? Зачем бандлы?
в том то и смысл что я хочу конфигурировать только app. gulp или грант по мере сохранения модели, вьюхи, шаблона конкретной страницы, сам будет смотреть что там есть в require и генерить из этого конфиг бандла. очень не хочется каждый раз ручками править конфиги по мере редактирования страницы - там может и мусор жить долго и счастливо ровно как и прохрененный редкоиспользуемый модуль который не протестили и т.д. ведь пропарсить файлики и регекспом выцепить зависимости дело простое если код не слишком мудрённый и не генерит имена модулей налету из разных параметров. если lmd умеет это делать сам, то это круто, я попробую научиться его готовить. да, что-то я постеснялся в конфиге генерить ключ бандлов)) это самый что ни на есть короткий путь к тому что я хочу запилить, спс!
у меня сингл-page бандлы нужны т.к. это видимо самый прямой способ дозагружать ресурсы во время выполнения основного сценария и главное их кешировать. как я понял конструкция вроде такой:
require.bundle(bundleName).done(function(){
page = new(require(pageName))({
el: el,
name: name,
data: data
})
})
загрузит бандл только 1 раз и собственно абсолютно беспроблемно сработает при повторном запросе. в случае множественной генерации js под каждую страницу у меня будет куча избыточного кода загрузчика и видимо неправославный require.js )
На счет бандлов понятно, да это их основной use-case.
Автопоска зависимостей по require нет. Потому как lmd не знает про файловую систему - использует абстрактуню на хэшах, поэтому модуль models/app.js
может иметь имя appModel
и прочее. Однако можно использовать какую-то существующую библиотеку для поиска зависимостей, например mine или node-detective или же grasp-equery и с помощью них сделать модуль, который построит динамический конфиг на основе зависимостей main файла.
Например, как-то так:
{
"modules": require('./look-for-dependencies-of')('./main.js')
}
LMD при сборке сканирует модули и может найти те, которые не используются. (Будет сообщение в логе сборки). Можно посмотреть в эту сторону.
Мы используем globing и с помошью него фактически 1-строкой подключаем пачку модулей, а не нужные модули, которые нашел сканер во время сборки вычищаем через "nonUsedModule": null
.
Пытался писать парсилку, но понял что вариант с "nonUsedModule": null более правильный. А как именно вы вычищаете nonUsedModule ? какой-то плагин вешаете или событие?
Чаще использую прямые зависимости. Когда модули декларируют в своих зависимостях(package.json) только ограниченный ряд других модулей. Тогда вычищать не нужно. Если же подключаю какую-то общую библиотеку для 2-х проектов, то вычищаю лишнее через null руками, глядя на варнинги при сборке.
Эхъ, жаль, придётся убивать в себе лень) было бы круто иметь либо ключик в конфиге, либо плагин слушающий событие о неиспользуемом модуле чтобы нулилось автоматом. хотя наверно проще допилить генерацию json файла со списком используемых модулей и инклюдить его в основном конфиге.
Спасибо, руками действительно намного веселей))
Привет. Не знаю является ли это проблемой, может я неправильно конфигурирую, но задавая в конфиге root некую директорию, для modules и bundles это является префиксом исходя из того, где находится сам файлик конфига, а для output префикс присоединяется к ".lmd" от той папки откуда мы запускаем lmd