Как и грозился — API кастом-процессоров теперь есть.
Неожидано — Handlebars не будет, авторы перемудрили с предкомпиляцией и я его прикрутить тупо не смог :)
Да, но делать так же в браузере — получишь ровно то, что туда положил — смысла как мне кажется никакого.
Я вот даже как-то и не знал, что она (node) так себя ведет :)
Посмотрел повнимательнее — Handlebars — вроде бы несложно, возможно добавлю в поддерживаемые шаблонизаторы.
С dust как-то мутновато, там идея немного не по формату такой компиляции, так что пока фик знает.
API для этого пока нет (и там много подумать надо будет), форкнуть и захардкодить — должно быть реально, смотрим здесь, при условии что у них есть аналог прекомпиляции, я их глубоко не копал.
Может быть в вашем смысле это чем-то оправдано, но в общем случае динамический require — это ммм… плохая идея.
Во-первых он очень синхронный — там куча всего под капотом происходит с суффиком Sync.
Во-вторых, потому что что-то надо было что-то делать с во-первых — он кеширует все вещи, которые были запрошены, в результате фактически в экземпляре процесса висят все штуки, которые были разрешены.
ИМХО лучшее, что тут можно сделать — сделать контейнер, который будет статически рекверить все, и отдавать отдельные элементы по имени. И подключить этот контейнер в код.
А можно у вас делать синонимы
Надеюсь что понял вопрос верно — да, можно, в конфиге пака есть ключ replacement, он как раз для таких вещей, но тут есть вопрос идеологии, о нем вот ниже.
А как включить jquery в бандл
Как бы идеологически использованиеи именно бандлов, а не какого-то app связано с тем, что clinch скорее аналог component, в том смысле что с его помощью можно делать маленькие виджеты, или кучу разных мелких хелперов. Если надо завернуть целый app — тут overhead не так страшен.
Поэтому немного неверно включать большие либы в бандл, их можно грузить отдельно, или, что правильнее — брать из CDN, а в бандле делать «пустышку», типа такой.
Пока все, что могу предожить для дебага — имена файлов как комментарий к коду, map source попробую прикрутить, но позднее. ИМХО юнит тесты + console.log() вполне решают проблему.
PS. Как-то с места в карьер начало статьи — проблема все равно не понятна — что значит «проверять»? Возможно стоит иметь как минимум 2 этапа — проверку и обработку и стыковать их, как принято в unix?
Надеюсь окажется полезным и мой спам еще не задолбал :)
Как и грозился — API кастом-процессоров теперь есть.
Неожидано — Handlebars не будет, авторы перемудрили с предкомпиляцией и я его прикрутить тупо не смог :)
Хотя, может у кого-то с API теперь и получится.
API для сторонних обработчиков будет, постараюсь сегодня выкатить до вечера.
С примером как прикручивается Handlebars.
Да, но делать так же в браузере — получишь ровно то, что туда положил — смысла как мне кажется никакого.
Я вот даже как-то и не знал, что она (node) так себя ведет :)
С dust как-то мутновато, там идея немного не по формату такой компиляции, так что пока фик знает.
Вообще-то код модуля вызывается в контексте глобали, т.е. this.jQuery должен найтись, если он в глобали есть.
Пруфф — здесь и ниже.
Иначе пустышка бы из примера выше не сработала бы.
Ну, т.е. надо до бандла просто подгрузить на страницу jQuery и все должно сработать.
Правда это навороченный вариант, с само-разрешением зависимостей, но идея именно такая.
Может быть в вашем смысле это чем-то оправдано, но в общем случае динамический require — это ммм… плохая идея.
Во-первых он очень синхронный — там куча всего под капотом происходит с суффиком Sync.
Во-вторых, потому что что-то надо было что-то делать с во-первых — он кеширует все вещи, которые были запрошены, в результате фактически в экземпляре процесса висят все штуки, которые были разрешены.
ИМХО лучшее, что тут можно сделать — сделать контейнер, который будет статически рекверить все, и отдавать отдельные элементы по имени. И подключить этот контейнер в код.
Надеюсь что понял вопрос верно — да, можно, в конфиге пака есть ключ
replacement
, он как раз для таких вещей, но тут есть вопрос идеологии, о нем вот ниже.Как бы идеологически использованиеи именно бандлов, а не какого-то app связано с тем, что clinch скорее аналог component, в том смысле что с его помощью можно делать маленькие виджеты, или кучу разных мелких хелперов. Если надо завернуть целый app — тут overhead не так страшен.
Поэтому немного неверно включать большие либы в бандл, их можно грузить отдельно, или, что правильнее — брать из CDN, а в бандле делать «пустышку», типа такой.
require
.Нет, такого мы не поддерживаем, просто в моем стиле кода это не используется. Кстати — профит-то в чем?
Для списка файлов и директорий clinch вряд ли подойдет — основная фишка как раз и была в нативной поддержке vanilla CommonJS из коробки, бо mocha.
Фидбек! Фидбек! :)
PS. Как-то с места в карьер начало статьи — проблема все равно не понятна — что значит «проверять»? Возможно стоит иметь как минимум 2 этапа — проверку и обработку и стыковать их, как принято в unix?
А жарить лучше на плите, у меня под это вок куплен, на всю семью можно зафигачить, с лучком :)
Уж тогда надо добавить, что из построенных не вообще, а NASA.
«Энергия» выводила до 105 тонн, в варинте «Вулкан» так и до 200 — всеж в вики есть.
(''+new Array(102)).split('')
некошерна, ИМХО.Вот так можно с дырками обходится.