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

Original author: Duojs.org
  • Translation
Duo — это новое поколение пакетного менеджера, который совмещает в себе лучшие идеи Component, Browserify и Go. Он предназначен для быстрого и безболезненного написания фронтового кода.



От переводчика: это практически дословный перевод сайта duojs.org. Зачем он здесь? Все просто: Duo — пакетный менеджер с которым я сейчас активно работаю. Мне он кажется удобным и поэтому появилось желание поделиться с сообществом (на хабре Duo не упоминался). И… И выслушать ваши мысли по поводу данного решения. А так как писать подробный скрупулезный доклад — не позволяет количество времени проведенного с Duo, решил просто сделать duojs.org чуточку доступней для русскоязычного пользователя.
 

Установим Duo при помощи npm


$ npm install -g duo

Duo необходима авторизация в Гитхаб для того чтобы увеличить rate limit и получить доступ к приватным репозиториям. Для этого нужно создать или изменить файл ~/.netrc и добавить следующую информацию:

machine api.github.com
  login <username>
  password <token>

<token> можно быстро создать по ссылке: github.com/settings/tokens/new


Приступим


Для включения кода из Гитхаба в традиционный JavaScript, просто напишите следующее:

var uid = require('matthewmueller/uid');
var fmt = require('yields/fmt');

var msg = fmt('Your unique ID is %s!', uid());
window.alert(msg);

Duo будет тянуть зависимости напрямую из репозиториев matthewmueller/uid и yields/fmt, расположенных на Гитхабе, без необходимости редактирования или создания каких-либо манифест-файлов.

Вы так же можете подключать модули прямо из файловой системы:

var modal = require('./modal/index.js');

Далее, используя команду duo, необходимо скачать зависимости и сбилдить файл:

$ duo index.js > build.js

И наконец, необходимо просто добавить тег <script> в HTML страницу:

<script src="build.js"></script>

Тоже самое сделаем и с CSS! Можно подключать зависимости и ресурсы напрямую из Гитхаба или файловой системы:

@import 'necolas/normalize.css';
@import './layout/layout.css';

body {
  color: teal;
  background: url('./background-image.jpg');
}

Соберем CSS с помощью Duo:

$ duo index.css > build.css

Добавим получившийся бандл в HTML-страницу:

<link rel="stylesheet" href="build.css">


Осообенности


  • нативная поддежка JavaScript, HTML и CSS
  • интерфейс для работы через командную строку для юникс-систем
  • выгружает код прямо из Гитахба, соблюдая семантическую версионность
  • поддерживает трансформации, например Coffescript или Sass
  • не требует манифест-файлов


Философия


Duo делает разработку невероятно простой в трех основных областях применения:

  • создание концептов или прототипов
  • написание модульных компонентов
  • разработка больших веб-приложений


Концепция


Как разработчикам, нам обычно необходимо потестировать какую то идею или локализовать баг. Одной из проблем в существующих пакетных менеджерах является: не возможность использовать пакетный менеджер без шаблонных файлов, таких как package.json или component.json.

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

var events = require('component/events');
var uid = require('matthewmueller/uid');

У вас есть возможность указывать версиии, ветки или пути к файлам:

var reactive = require('component/reactive@0.14.x');
var tip = require('component/tip@master');
var shortcuts = require('yields/shortcuts@0.0.1:/index.js');

Тоже самое можно провернуть для CSS, используя import:

@import 'necolas/normalize.css';
@import 'twbs/bootstrap@v3.2.0:dist/css/bootstrap.css';

Вы можите подключить .html или .json файлы:

var template = require('./menu.html');
var schema = require('./schema.json');

Duo позабоится о том, чтобы преобразовать .html в JavaScript стоку, а .json в JavaScript объект.

Когда все будет готово для билда, просто запустите:

$ duo in.js > out.js
$ duo in.css > out.css


Веб-приложения


Для того чтобы пакетный менеджер был по настоящему полезным, он должен быть масштабируемым, другими словами подходить как для простых так и для более сложных приложений. В этом смысле, Duo делает процесс масштабирования почти незаметным.

Duo позволяет собрать несколько страниц за раз. Для того чтобы сделать поиск кода в файлах проще, вы можете разделить ваше приложение на несколько бандлов. Чтобы собрать несколько бандлов за раз — просто передайте их, как параметры duo:

$ duo app/home.js app/about.js app/admin.js

И вариант с фигурными скобками:

$ duo app/{home,about,admin}/index.{js,css}


При сборке, если Duo попадается путь к ресурсу, например рисунок или шрифт — тогда этот ресурс автоматически включается в директорию build/. Например, у нас есть изображение в CSS файле:

@import 'necolas/normalize.css';

body {
  background: url('./images/duo.png');
}

Duo создаст симлинк build/images/duo.png. Можно просто развернуть веб-сервер на директорию build/ — в ней уже лежит готовый к деплою проект.
 

Примеры


Несколько живых проектов лежат в этих репозиториях на Гитхабе:



Сообщество


За подробной информацией можно обратиться к следующим источникам:



Дополнено:
В комментариях подбросили ссылку на интересный инструмент http://webpack.github.io/.
Duo поддерживает пакеты npm и bower. Есть JavaScript API, duo-gulp, а так же утилита для автоматического билда watch.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 60

    +1
    А какие минусы у этого Duo? И преимущества перед bower и npm?
      0
      Перечисленные вами пакетные менеджеры просто выкачивают зависимости.
      Обычно для включения зависимостей в HTML-страницу используют requirejs.

      Здесь же что то среднее. Но из плюсов:
      — отсутствие манифест-файлов
      — упрощенная процедура создания компонента и последующего его использования (просто выгрузить на гитхаб и подключить через require)
      — этот пакетный менеджер поддерживает npm и bower
      — подключение ресурсов templates, images etc.
      — наличяие вполне используемых и приятных плагинов Hogan (mustache templates compiler), Sass, Less, etc.
        0
        А из минусов: нужно собирать билд. Но для этого вроде бы есть вотчер: github.com/duojs/watch
        Более минусов подсказать не могу — опыт общения с Duo около месяца.
          +2
          А как у него с source map'ами? Как дебажить зависимости с гитхаба?
            0
            Сколько длится сборка? Приведите, пожалуйста, количество модулей (примерно, конечно) и время?
              0
              В данный момент я тестирую Duo на небольшом проекте. Проект на данном этапе небольшой. Зависимостей примерно 10. Пару библиотек для ajax/collections, и около 8 темплейтов. Средний билд 0m2.187s.
                0
                У вас SSD?
                  0
                  Обычный.
                    0
                    Ясно, спасибо.
            +1
            ну например если вы тянете библиотеку напрямую из репозитория, то после ее обновления она обновится и у вас. а это не очень хорошо, потому что может быть поломана обратная совместимость.
            +5
            Мне лично не понравился подход с указанием имени пользователя и пакета. А так browserify и gulp наше все.
              0
              Мне не понравилось в browserify замкнутость на npm. gulp никто не мешает использовать: www.npmjs.org/package/duo-gulp

              И хочется поинтересоваться, а в чем минус использовать имя пользователя/пакет, это ведь только для проектов на Гитхабе. Можно подключать локальные файлы.
                +2
                Ну вообще то он не замкнут на npm (точнее это легко нивелируется, хотя я не считаю что npm плохо), н-р ставится debowerify и тянется из bower (есть тоже самое для requirejs). Я лично часто в gulpfile прописывал пути самостоятельно для вызова browserify.
                Видимо тут на любителя.
                  0
                  Полностью солидарен.
                  +6
                  В то время как 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
                    0
                    А если указывать в require() название пакета — он разве не из npm/bower тянется?
                      0
                      Судя по скомпиленному результату — нет. Надо модуль отдельно указывать в component.json, чтобы он тянулся [откуда угодно].
                    +1
                    Если вы о завязанности на реестр npm, то это не так — можно ставить зависимости с GitHub или любого git-эндпоинта. Также с версии 2 можно использовать свои реестры приватных пакетов. То есть npm прекрасно работает с кастомным реестром или без оного, как, например, это делает bower.
                    А если вы о завязанности на сам API npm, то это есть. Но разве тут есть что-то плохое? npm весьма хорош.
                  +2
                  Минус — нет поддержки пакетов npm
                    0
                    Вроде как есть поддержка 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.
                      0
                      Кстати, это забавно, что ребята предлагаю создать component.json и использовать duo как component :)
                        0
                        Насколько я понял, Duo вобрал в себя костяк из команды ComponentJs. Где то читал, что Duo стал логическим продолжением ComponentJs. Как то так.
                    0
                    если нужна подсветка в редакторе( для подключаемые библиотек типа Bourbon), то я так понимаю, мне все равно надо будет скачивать ее отдельно каждый раз, когда я должен разворачиваться проект?
                      0
                      Вы о зависимостях в стилях? Полагаю, что нужно сбилдить. IDE сама по себе не сможет ведь понять, что @ import 'user/repo' это отсылка к Гитхаб репозиторию.

                      А какая IDE, если не секрет?
                        0
                        Нет человек наверное говорит про авто-дополнение кода. По идее собранный проект собранным, а исходники отдельно. По этому надо выкачивать исходники и использовать jsdoc, чтобы подсвечивалось правильно.
                          +1
                          В том и дело, дев окружение — это дев окружение и оно для разработки, а билд — это уже для продакшене, или чтобы иметь code complete мне нужно билд пересобирать каждый раз.

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

                          в случае duo.js воркфлоу так понимаю такой, иду на гитхаб и ищу то, что мне нужно и добавляю к себе в проект, при этом все зависимости у меня раскиданы по проекту и нигде в явном виде не объявлены ( файла манифеста ведь нет), все верно?
                            0
                            Да, в целом верно. За исключением того, что есть возможность подключать локальные js-файлы.
                            В таком случае есть componentjs где можно указывать зависимости в явном виде.
                            Хотя и duojs тоже дает возможность указывать зависимости в component.json файле, если это необходимо.
                        0
                        Js файлы должны быть подготовлены для него (commonjs) все подряд через
                        var fmt = require('....');
                        

                        не подключишь?
                          0
                          Можно все подряд, но ничего не будет экспортировано.

                          require('./jquery.js');
                          
                          0
                          Может ли он выделять общий код в отдельный чанк?
                          Может ли он разбивать большой билд на несколько чанков и автоматически их грузить?
                          Может ли он загружать код по требованию объединив его в отдельный чанк?

                          п.с. под словом код я подразумеваю код css, js, html и пр.
                            0
                            Под чанками вы наверное имеете ввиду, чтобы код был вынесен в условно-говоря отдельный файл, чтобы в браузере было проще искать где вылезла ошибка?
                              0
                              Не совсем, чанки это куски билда. Например итоговый билд у меня получается скажем 1мб, можно ли в Duo указать что бы он разбивал такие файлы на несколько более мелких файлов, и при этом сам их грузил?
                                0
                                Предполагаю, что нельзя. Но я могу ошибаться.

                                Скорей всего прийдется разделять самостоятельно и грузить через динамически-создаваемый SCRIPT.
                                  +2
                                  ну тогда эта штука для больших проектов не подходит. тот же webpack умеет это из коробки
                                    0
                                    Согласен, но пока разбираюсь, может где то недоглядел.
                              +3
                              давно разочаровался в browserify и думают вам подойдет webpack.github.io/ как и мне в свое время.
                                0
                                Выглядит прекрасно, попробую, спасибо!
                                  +3
                                  А чем, собственно, разочаровались?
                                +3
                                Не люблю opinionated инструменты. Что если нужный мне модуль не поддерживает commonjs? C bower куда проще в этом отношении, не надорвусь один раз сделать bower init в начале проекта.
                                  0
                                  Пишут что «нового поколения» а поддержки модулей из ES6 нету.

                                  Не знаю кому вообще это нужно… gulp, gulp-inject, bowerMainFiles, traceur + es6 module loader и вперед.
                                    0
                                    То, что генерирует traceur выглядит просто УЖАСНО! Нашел для себя более гуманный вариант github.com/sebmck/6to5 и есть лоадер под webpack github.com/Couto/6to5-loader. В общем пока не жаловался. И вот пример моего gulp файла, как я использую webpack и 6to5 github.com/xgrommx/angular-vk-app/blob/master/gulpfile.js.
                                      0
                                      Ну не так уж все и страшно там внутри, да и какая разница что он там генерит если у нас есть sourcemaps и оно работает. Да и насколько я понял 6to5-loader только для сборки. es6-module-loader же позволяет не производить сборку а является своего рода полифилом для ES6.
                                      0
                                      Уровень вовлеченности в js у всех разный. Но, как производитель заявил — так и написали. :)
                                      Я для себя отвел нишу для Duo, как для инструмента «бстро написать прототип», без необходимости настраивать gulp и похожие билд-системы.

                                      Конечно для больших проектов еще необходимо оценить его значимость и применимость.
                                        0
                                        Да, пожалуй для «быстро написать прототип» норм. Хотя можно gulp usemin использовать или что-то подобное. Идея то не новая. Так же обычно разработчики делают для себя какой-то дефолтный сборщик под свою структуру проектов.
                                          0
                                          usemin да, понравилось сначала. Тут история немножко другая. У меня уже было написано ряд компонентов с экспортом в духе CommonJS. Поэтому было желание помимо обычной минификации иметь возможность более человечно подключать их. Duo неплохо вписался, но судя по комментариям — буду присматриваться и к более прогрессивным решениям.
                                        • UFO just landed and posted this here
                                            0
                                            а для любителей gulp был создан slushjs.github.io
                                            • UFO just landed and posted this here
                                        +1
                                        Duo необходима авторизация в Гитхаб для того чтобы увеличить скорость доступа к пакетам

                                        Чего? По протоколу git:// публичные репозитории и так отдаются.
                                          0
                                          Да, этот момент и для меня не совсем ясен — авторизацию хочет, якобы для того чтобы быстрей скачивать пакеты + в перспективе иметь доступ к собственным приватным репозиториям. Я о тонкостях доступа с авторизацией, признаться сам не знаю. И есть ли смысл в этом (скорость).
                                            0
                                            так же как и brew, composer, bower и т.д. Они все хотят получить токен на доступ к вашему аккаунту (заметте, не логин и пароль). Дело в том наверное что для неавторизованных пользователей API имеет очень жесткие ограничения по количеству запросов за еденицу времени.
                                              0
                                              Но дело явно не в скорости. Дело в лимите, или статистике, или еще чем-то.
                                                0
                                                ну например npm успешно ставит приватные пакеты из гита через git+ssh, тут должно быть что то подобное, имхо.
                                                  0
                                                  да. Но при чем тут скорость?
                                                    +1
                                                    Попробую расставить все точки…

                                                    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:

                                                    Я перевел как «увеличить скорость доступа к пакетам». Возможно, мой перевод не совсем отражает суть, но ограничения действительно имеют место.
                                                      0
                                                      Ну тут не про скорость, а про количество. Дословно, для авторизованных запросов стоит ограничение на 5000 запросов в час, для анонимных 60, причем на 1 ип. Собственно на Duo об этом и сказано.
                                            –2
                                            ⃞∇⊚.js (иⱯи я что-то путаю?)
                                              0
                                              ☆◯☐△.js
                                              0
                                              создание концептов или прототипов

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

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

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

                                              Only users with full accounts can post comments. Log in, please.