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

Question

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

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

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

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

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

Answer 1

Я думал об этом сам, и я пришел к нескольким выводам:

1. Создать одну версию структуры, которая может быть использована как в глобальном, так и AMD установка
2. Не обольщайтесь необходимости попросите своих клиентов включить зависимости вручную, это однопроцессорная деятельность, и в любом случае должно быть сделано , независимо от того, предоставляете ли вы инфраструктуру AMD или инфраструктуру с глобальным охватом (размещение сторонних зависимостей должно быть скорректировано в любом случае, это что я говорю)
3. Я использую Grunt для pro ject building/packaging/testing/linting/whatever, поэтому для всех других альтернатив упаковки у меня разные задачи.

Итак, вкратце, сначала создайте для «старой школы/AMD» пакет для «нового поколения».

P.S.

Я также твердо убежден в том, что ваша упаковка и процесс доставки/необходимости не должны (когда это возможно) диктовать свои архитектурные решения и решения в области развития.

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