Як сьогодні модулювати і упакувати клієнтську бібліотеку Javascript?

Я наздогнав сучасну екосистему JS на стороні клієнта і читав на CommonJS та AMD (включаючи пов'язані інструменти - перегляньте, Requjs, Onejs, Jam, десятки інших). Якщо я пишу бібліотеку Javascript, як я модулюю / пакую її таким чином, щоб вона була найбільш доступною (в ідеалі користувачами, які клянуться у CommonJS, AMD, а особливо ні)?

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

Чи, можливо, найпростішим є створення декількох версій моєї бібліотеки для кожного контексту?

Мене теж цікавить упаковка та публікація. Є декілька систем, але я вважаю, що головна - це каналізація, з якою легко впоратися, оскільки все, що вона робить, - це отримання. Однак мені цікаво, чи слід також орієнтуватися на інші системи пакетів, як компонент (для чого потрібен CommonJS).

Чи є інші відповідні аспекти, про які я маю знати? Чи є якісь хороші приклади проектів, які слід наслідувати для всього цього?

Я завжди використовував файли збірки, але, оскільки я запустив свій перший проект nodejs, я почав використовувати переглядати . За допомогою browerify та інших подібних бібліотек ваш код - це файл збірки. Я використовую клієнтську та серверну бібліотеку, яка може працювати на обох, але вона також може працювати з суто клієнтським кодом. Підсумовуючи це, браузер дає всі переваги написання коду у вузол (немає функцій, що не дозволяють уникати глобальних, npm, простих, необхідних), і це дозволяє упакувати цей код для запуску на клієнті за допомогою однієї команди та завантаження лише одного файлу.

За допомогою перегляду веб-сторінок ви можете зробити щось на зразок (з назвою 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');
}

перегляньте 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 і просто вимагати від користувача $ і _. Я б запропонував розмістити більш незрозумілі libs як частину пакетного файлу. Варіанти також не потрібно різати і сушити. Ви можете запропонувати попередньо побудований або скласти власний пакет.

Види бібліотек на базі клієнта:

1. Зачіпає DOM
2. Не торкається DOM

З першим видом (віджети інтерфейсу тощо) ви, як правило, припускаєте, що jQuery присутній. Ви також можете написати "агностик бібліотеки DOM", щоб він працював і з менш популярними, але я не переймаюся.

З другим видом. Перш за все, не робіть його плагіном jQuery, наприклад, "плагін cookie jQuery" є смішним, але така бібліотека насправді існує.

Обидва ці види можуть не мати залежностей, малих або величезних залежностей - при цьому бібліотека dom не вважається залежністю в цьому сенсі. З першими 2 ви просто об'єднаєте їх у межах вашої бібліотеки і не переживаєте про можливе дублювання. Наприклад, jQuery об'єднує внутрішню isArrayLikeфункцію, навіть незважаючи на те, що користувач може мати свою власну вже включену в якусь випадкову бібліотеку стрічкових програм.

У мене є лише один особистий досвід з величезною залежністю при розробці бібліотеки (власне мови) - moment.js. У цьому випадку я б запропонував 2 збірки, одну з об'єднаними moment.js і одну без, де користувач несе відповідальність за включення її. Я не знаю, чи це хороше рішення.

І так, у кожному випадку застосовується підхід jQuery про створення одного останнього великого файлу, який просто працює. У нижній частині котла модуля (виявлення вимагає / AMD / глобального тощо).