Как модулировать и упаковать клиентскую библиотеку Javascript сегодня?

Я знакомлюсь с современной клиентской экосистемой JS и изучаю CommonJS и AMD (включая связанные инструменты - browserify, requirejs, onejs, jam, десятки других). Если я пишу библиотеку Javascript, как мне упаковать / упаковать ее так, чтобы она была наиболее доступной (в идеале, пользователям, которые клянутся CommonJS, AMD и особенно ни тем, ни другим)?

Популярные библиотеки, такие как jQuery, по-видимому, просто используют конкатенацию файлов старой школы для построения себя и динамически определяют, должна ли она выполнять запись exportsв глобальный или глобальный контекст. В настоящее время я делаю то же самое, но главный недостаток заключается в том, что если я (в отличие от jQuery) зависит от нескольких библиотек, то неплохо бы не просить пользователей вручную предварительно включать транзитивный набор. (Хотя в настоящее время у меня просто две зависимости.) И, конечно же, загрязнение пространства имен в глобальном масштабе.

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

Я также интересуюсь упаковкой и публикацией. Существует несколько систем, но я считаю, что главная из них - бауэр, с которым легко иметь дело, так как все, что она делает, это извлекает. Однако мне интересно, должен ли я также ориентироваться на другие системы пакетов, такие как компонент (который требует CommonJS).

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

Я всегда использовал файлы сборки, но с тех пор, как начал свой первый проект nodejs, я начал использовать browserify . С browerify и другими подобными библиотеками ваш код является вашим файлом сборки. Я пользуюсь клиентской и серверной библиотекой, которая может работать как на обоих, так и на чистом клиентском коде. Подводя итог, мы можем сказать, что browserify дает вам все преимущества написания кода в узле (нет функций anon, позволяющих избежать глобальных переменных, npm, простых требований) и позволяет упаковать этот код для запуска на клиенте одной командой и загрузить только один файл.

С browserify вы можете сделать что-то вроде (с именем app.js):

var MyLib = require('../myLib');

if(typeof window !== 'undefined') {
    window.MyLib = MyLib;
    window._ = require('underscore');
    window.$ = require('$');
    window.MyLib.myCan = require('./3rdParty/can/can');
}

browserify app.js> client.js

Будет производить что-то вроде:

[function(require,module,exports){
    window.MyLib = //MyLib code
},
function(require,module,exports){
     window._ = //_ code
},
function(require,module,exports){
    window.$ = //$ code
},
function(require,module,exports){
    window.MyLib.myCan = //can code
}

В файле, который вы бы определили, могут быть включены все ваши сторонние библиотеки, и он не будет конфликтовать с кем-либо из ваших разработчиков, которые его используют.

- Редактировать в ответ на комментарий (и полный промах по вопросу)

Я думаю, это будет зависеть от ваших зависимостей и того, сколько времени вы хотите потратить, чтобы убедиться, что они работают на всех версиях и библиотеках. Если ваши зависимости являются общими и следуют одному и тому же API от версии к версии, вы можете пойти по пути Backbone и просто потребовать, чтобы у пользователя были $ и _. Я бы посоветовал поместить более неизвестные библиотеки в состав файла. Варианты не должны быть сокращены и высушены также. Вы можете предложить готовый пакет или создать свой собственный пакет.

Виды клиентских библиотек:

1. Прикосновения ДОМ
2. Не касается DOM

С первым видом (виджеты пользовательского интерфейса и т. Д.) Вы обычно предполагаете, что присутствует jQuery. Вы также можете написать «Независимость от библиотеки DOM» и заставить ее работать с менее популярными, но я не беспокоюсь.

Со вторым видом. Прежде всего, не делайте его плагином jQuery, например, «плагин cookie jQuery» - это просто смешно, но такая библиотека действительно существует.

Оба этих типа могут не иметь зависимостей, небольших или огромных зависимостей - с библиотекой dom, не считающейся зависимостью в этом смысле. С первыми двумя вы просто объедините их внутри своей области библиотеки и не будете беспокоиться о возможном дублировании. Например, jQuery объединяет внутреннюю isArrayLikeфункцию, даже если пользователь может включить свою собственную из некоторой случайной библиотеки служебных поясов.

У меня есть только один личный опыт с огромной зависимостью при разработке библиотеки (на самом деле язык) - moment.js. В этом случае я бы предоставил 2 сборки, одну с каскадом moment.js, а другую без, где пользователь отвечает за ее включение. Я не знаю, если это хорошее решение, хотя.

И да, в любом случае, подход jQuery для создания одного окончательного большого файла, который просто работает, принят. Он имеет шаблон модуля внизу (требуется / AMD / Global и т. Д. Обнаружения).