Duo.js — новое поколение пакетного менеджера для фронтэнда

[@kresh]

А какие минусы у этого Duo? И преимущества перед bower и npm?

[@jMas]

Перечисленные вами пакетные менеджеры просто выкачивают зависимости.
Обычно для включения зависимостей в HTML-страницу используют requirejs.

Здесь же что то среднее. Но из плюсов:
— отсутствие манифест-файлов
— упрощенная процедура создания компонента и последующего его использования (просто выгрузить на гитхаб и подключить через require)
— этот пакетный менеджер поддерживает npm и bower
— подключение ресурсов templates, images etc.
— наличяие вполне используемых и приятных плагинов Hogan (mustache templates compiler), Sass, Less, etc.

[@jMas]

А из минусов: нужно собирать билд. Но для этого вроде бы есть вотчер: github.com/duojs/watch
Более минусов подсказать не могу — опыт общения с Duo около месяца.

[@nightstalker]

А как у него с source map'ами? Как дебажить зависимости с гитхаба?

[@k12th]

Сколько длится сборка? Приведите, пожалуйста, количество модулей (примерно, конечно) и время?

[@jMas]

В данный момент я тестирую Duo на небольшом проекте. Проект на данном этапе небольшой. Зависимостей примерно 10. Пару библиотек для ajax/collections, и около 8 темплейтов. Средний билд 0m2.187s.

[@k12th]

У вас SSD?

[@jMas]

Обычный.

[@k12th]

Ясно, спасибо.

[@fetis26]

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

[@btd]

Мне лично не понравился подход с указанием имени пользователя и пакета. А так browserify и gulp наше все.

[@jMas]

Мне не понравилось в browserify замкнутость на npm. gulp никто не мешает использовать: www.npmjs.org/package/duo-gulp

И хочется поинтересоваться, а в чем минус использовать имя пользователя/пакет, это ведь только для проектов на Гитхабе. Можно подключать локальные файлы.

[@btd]

Ну вообще то он не замкнут на npm (точнее это легко нивелируется, хотя я не считаю что npm плохо), н-р ставится debowerify и тянется из bower (есть тоже самое для requirejs). Я лично часто в gulpfile прописывал пути самостоятельно для вызова browserify.
Видимо тут на любителя.

[@jMas]

Полностью солидарен.

[@Dmitry_f]

В то время как browserify замкнут на npm (хотя это вообще-то пока что самый некостыльный и стандартный способ реализации зависимостей в js), duo вообще игнорит npm. Не понимаю зачем. Уж могли бы сделать его npm-compliant, типа, без указания автора зависимость тянется из npm или по указанию из package.json. Можно было бы безболезненно использовать duo для замены npm, типа мне удобнее забыть о `package.json`, но менять привычку писать обычный node-код я не собираюсь. Можно было бы просто взять и весь текущий код использовать через duo. А так получается, что компонент для duo и компонент для npm это разные вещи. Доверие снижается.

Плюс ребята таргетятся на префиксирование неймспейсов компонентов через указание авторства, но по факту это задачу усложняет, а не решает: большинство имен пользователей на гитхабе набраны в соответствии с локалью, к примеру, вписывать французские или японские ники авторов оказывается большей болью, чем вписывать «хипстерские» названия модулей. Ну и что, что есть tooltip, component-tooltip, micro-tip, tippy, tip, tipster и еще десяток тултипов — это понятнее и лучше, чем aufbersht/tooltip, component/tooltip, jamesc/tooltip, obie/tooltip, elian/tooltip… которые идентифицируются не языковой игрой и впечатлением, а смутным локальным именем автора, которое вообще ни о чем не говорит.

Помимо этого всего, пока ты пишешь стандартный компонент, ты хочешь использовать максимально стандартные и универсальные средства. Если я буду писать компонент для duo, я автоматически срезаю аудиторию не-duo пользователей. Это невероятно глупо. Если же я пишу кастомное приложение и мне нужен удобный инструмент — ума не приложу, почему именно duo — ведь странно не иметь у большого приложения всякие инструменты настройки/сборки.

Таким образом, duo встает на одну ступень с component, за исключением того, что у второго надо сгенерить файл component.json

[@jMas]

А если указывать в require() название пакета — он разве не из npm/bower тянется?

[@Dmitry_f]

Судя по скомпиленному результату — нет. Надо модуль отдельно указывать в component.json, чтобы он тянулся [откуда угодно].

[@StreetStrider]

Если вы о завязанности на реестр npm, то это не так — можно ставить зависимости с GitHub или любого git-эндпоинта. Также с версии 2 можно использовать свои реестры приватных пакетов. То есть npm прекрасно работает с кастомным реестром или без оного, как, например, это делает bower.
А если вы о завязанности на сам API npm, то это есть. Но разве тут есть что-то плохое? npm весьма хорош.

[@xGromMx]

Минус — нет поддержки пакетов npm

[@jMas]

Вроде как есть поддержка npm пакетов, нужно покопаться в репозитории, чтобы выяснить как это правильно делать. github.com/duojs/duo/issues/275

И еще из FAQ:

What about Browserify?

Browserify is a great project and if it's working well for you then you should keep using it.

Duo's scope is much more ambitious. Duo aims to be your go-to asset pipeline for Node.js. Much in the same way that Sprockets is for the Ruby community.

Browserify's dependence on NPM to deliver it's packages leads to some big issues:

— naming is a bigger hassle on the client-side (how many different kinds of tooltips are there?)
— private modules require a private NPM server
— ensuring your team has push access to each module is always a pain, especially when a teammate leaves
— By using GitHub as your package manager all of these issues disappear.

[@Dmitry_f]

Кстати, это забавно, что ребята предлагаю создать component.json и использовать duo как component :)

[@jMas]

Насколько я понял, Duo вобрал в себя костяк из команды ComponentJs. Где то читал, что Duo стал логическим продолжением ComponentJs. Как то так.

[@VitaLik_is_goodman]

если нужна подсветка в редакторе( для подключаемые библиотек типа Bourbon), то я так понимаю, мне все равно надо будет скачивать ее отдельно каждый раз, когда я должен разворачиваться проект?

[@jMas]

Вы о зависимостях в стилях? Полагаю, что нужно сбилдить. IDE сама по себе не сможет ведь понять, что @ import 'user/repo' это отсылка к Гитхаб репозиторию.

А какая IDE, если не секрет?

[@Claud]

Нет человек наверное говорит про авто-дополнение кода. По идее собранный проект собранным, а исходники отдельно. По этому надо выкачивать исходники и использовать jsdoc, чтобы подсвечивалось правильно.

[@VitaLik_is_goodman]

В том и дело, дев окружение — это дев окружение и оно для разработки, а билд — это уже для продакшене, или чтобы иметь code complete мне нужно билд пересобирать каждый раз.

И в целом не ясен воркфлоу по этому пакетному менеджеру,
в случае bower — это bower s something и bower install something --save не выходя из командной строки + возможность code complete для подключенных файлов

в случае duo.js воркфлоу так понимаю такой, иду на гитхаб и ищу то, что мне нужно и добавляю к себе в проект, при этом все зависимости у меня раскиданы по проекту и нигде в явном виде не объявлены ( файла манифеста ведь нет), все верно?

[@jMas]

Да, в целом верно. За исключением того, что есть возможность подключать локальные js-файлы.
В таком случае есть componentjs где можно указывать зависимости в явном виде.
Хотя и duojs тоже дает возможность указывать зависимости в component.json файле, если это необходимо.

[@Claud]

Js файлы должны быть подготовлены для него (commonjs) все подряд через

var fmt = require('....');

не подключишь?

[@jMas]

Можно все подряд, но ничего не будет экспортировано.

require('./jquery.js');

[@zxcabs]

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

п.с. под словом код я подразумеваю код css, js, html и пр.

[@jMas]

Под чанками вы наверное имеете ввиду, чтобы код был вынесен в условно-говоря отдельный файл, чтобы в браузере было проще искать где вылезла ошибка?

[@zxcabs]

Не совсем, чанки это куски билда. Например итоговый билд у меня получается скажем 1мб, можно ли в Duo указать что бы он разбивал такие файлы на несколько более мелких файлов, и при этом сам их грузил?

[@jMas]

Предполагаю, что нельзя. Но я могу ошибаться.

Скорей всего прийдется разделять самостоятельно и грузить через динамически-создаваемый SCRIPT.

[@zxcabs]

ну тогда эта штука для больших проектов не подходит. тот же webpack умеет это из коробки

[@jMas]

Согласен, но пока разбираюсь, может где то недоглядел.

[@xGromMx]

давно разочаровался в browserify и думают вам подойдет webpack.github.io/ как и мне в свое время.

[@jMas]

Выглядит прекрасно, попробую, спасибо!

[@Dmitry_f]

А чем, собственно, разочаровались?

[@k12th]

Не люблю opinionated инструменты. Что если нужный мне модуль не поддерживает commonjs? C bower куда проще в этом отношении, не надорвусь один раз сделать bower init в начале проекта.

[@Fesor]

Пишут что «нового поколения» а поддержки модулей из ES6 нету.

Не знаю кому вообще это нужно… gulp, gulp-inject, bowerMainFiles, traceur + es6 module loader и вперед.

[@xGromMx]

То, что генерирует traceur выглядит просто УЖАСНО! Нашел для себя более гуманный вариант github.com/sebmck/6to5 и есть лоадер под webpack github.com/Couto/6to5-loader. В общем пока не жаловался. И вот пример моего gulp файла, как я использую webpack и 6to5 github.com/xgrommx/angular-vk-app/blob/master/gulpfile.js.

[@Fesor]

Ну не так уж все и страшно там внутри, да и какая разница что он там генерит если у нас есть sourcemaps и оно работает. Да и насколько я понял 6to5-loader только для сборки. es6-module-loader же позволяет не производить сборку а является своего рода полифилом для ES6.

[@jMas]

Уровень вовлеченности в js у всех разный. Но, как производитель заявил — так и написали. :)
Я для себя отвел нишу для Duo, как для инструмента «бстро написать прототип», без необходимости настраивать gulp и похожие билд-системы.

Конечно для больших проектов еще необходимо оценить его значимость и применимость.

[@Fesor]

Да, пожалуй для «быстро написать прототип» норм. Хотя можно gulp usemin использовать или что-то подобное. Идея то не новая. Так же обычно разработчики делают для себя какой-то дефолтный сборщик под свою структуру проектов.

[@jMas]

usemin да, понравилось сначала. Тут история немножко другая. У меня уже было написано ряд компонентов с экспортом в духе CommonJS. Поэтому было желание помимо обычной минификации иметь возможность более человечно подключать их. Duo неплохо вписался, но судя по комментариям — буду присматриваться и к более прогрессивным решениям.

[@xGromMx]

а для любителей gulp был создан slushjs.github.io

[@hell0w0rd]

Duo необходима авторизация в Гитхаб для того чтобы увеличить скорость доступа к пакетам

Чего? По протоколу git:// публичные репозитории и так отдаются.

[@jMas]

Да, этот момент и для меня не совсем ясен — авторизацию хочет, якобы для того чтобы быстрей скачивать пакеты + в перспективе иметь доступ к собственным приватным репозиториям. Я о тонкостях доступа с авторизацией, признаться сам не знаю. И есть ли смысл в этом (скорость).

[@Fesor]

так же как и brew, composer, bower и т.д. Они все хотят получить токен на доступ к вашему аккаунту (заметте, не логин и пароль). Дело в том наверное что для неавторизованных пользователей API имеет очень жесткие ограничения по количеству запросов за еденицу времени.

[@hell0w0rd]

Но дело явно не в скорости. Дело в лимите, или статистике, или еще чем-то.

[@zxcabs]

ну например npm успешно ставит приватные пакеты из гита через git+ssh, тут должно быть что то подобное, имхо.

[@hell0w0rd]

да. Но при чем тут скорость?

[@jMas]

Попробую расставить все точки…

https://developer.github.com/v3/#rate-limiting

For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour. Unauthenticated requests are associated with your IP address, and not the user making requests. Note that the Search API has custom rate limit rules.

На сайте duojs.org, цитирую:

Duo requires you to authenticate with GitHub to increase your rate limit and allow you to pull from private repositories. To do that, add the following entry to your ~/.netrc file:

Я перевел как «увеличить скорость доступа к пакетам». Возможно, мой перевод не совсем отражает суть, но ограничения действительно имеют место.

[@zxcabs]

Ну тут не про скорость, а про количество. Дословно, для авторизованных запросов стоит ограничение на 5000 запросов в час, для анонимных 60, причем на 1 ип. Собственно на Duo об этом и сказано.

[@spmbt]

⃞∇⊚.js (иⱯи я что-то путаю?)

[@Mithgol]

☆◯☐△.js

[@fetis26]

создание концептов или прототипов

вполне подойдет.

разработка больших веб-приложений

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

[@arXangel]

Голосовать уже за коммент нельзя, но я с вами полностью согласен, сейчас использую browserify + grunt/gulp.