Jak dziś zmodularyzować i spakować bibliotekę JavaScript po stronie klienta?

Nadrabiam zaległości w nowoczesnym ekosystemie JS po stronie klienta i czytam o CommonJS i AMD (w tym powiązanych narzędziach - Browserify, wymagania, onejs, jam, dziesiątki innych). Jeśli piszę bibliotekę JavaScript, jak mogę ją zmodularyzować / spakować w taki sposób, aby była jak najszerzej dostępna (najlepiej dla użytkowników, którzy przysięgają na CommonJS, AMD, a zwłaszcza żaden)?

Wydaje się, że popularne biblioteki, takie jak jQuery, używają old-schoolowej konkatenacji plików do samodzielnego budowania i dynamicznie wykrywają, czy powinny pisać exportsw kontekście globalnym, czy też. Obecnie robię to samo, ale głównym minusem jest to, że jeśli (w przeciwieństwie do jQuery) polegam na kilku bibliotekach, miło jest nie prosić użytkowników o ręczne wstępne włączenie zestawu przechodniego. (Chociaż obecnie mam tylko dwie zależności.) I oczywiście globalne zanieczyszczenie przestrzeni nazw.

A może najczystsze jest generowanie wielu wersji mojej biblioteki dla każdego kontekstu?

Zastanawiam się także nad pakowaniem i publikowaniem. Istnieje kilka systemów, ale uważam, że głównym jest altana, z którą łatwo sobie poradzić, ponieważ wystarczy pobrać. Zastanawiam się jednak, czy powinienem również celować w inne systemy pakietów, takie jak komponent (który wymaga CommonJS).

Czy są inne istotne aspekty, o których powinienem wiedzieć? Czy są jakieś dobre przykładowe projekty do naśladowania w tym zakresie?

Zawsze używałem plików kompilacji, ale odkąd zacząłem swój pierwszy projekt nodejs, zacząłem używać Browserify . W przypadku browerify i innych podobnych bibliotek kod jest plikiem kompilacji. Korzystam z biblioteki klienta i serwera, która może działać na obu, ale może również współpracować z kodem czysto klienta. Podsumowując, browserrify daje wszystkie zalety pisania kodu w węźle (brak funkcji anonowych w celu uniknięcia globalizacji, npm, proste wymagania) i pozwala spakować ten kod do uruchomienia na kliencie za pomocą jednej komendy i załadowania tylko jednego pliku.

Z Browserify możesz zrobić coś takiego (o nazwie 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

Wyprodukowałby coś takiego:

[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
}

Plik, który zdefiniujesz, może zawierać wszystkie biblioteki innych firm i nie może kolidować z żadnym programistą, który go używa.

- Edytuj w odpowiedzi na komentarz (i kompletne pominięcie pytania)

Myślę, że to zależy od twoich zależności i tego, ile czasu chcesz poświęcić, upewniając się, że działają one we wszystkich wersjach i bibliotekach. Jeśli twoje zależności są wspólne i postępuj zgodnie z tym samym interfejsem API od wersji do wersji, możesz przejść trasę kręgosłupa i po prostu wymagać od użytkownika posiadania $ i _. Sugerowałbym umieszczenie bardziej niejasnych bibliotek jako część dołączonego pliku. Opcje też nie muszą być wycięte i wysuszone. Możesz zaoferować gotową lub zbudować własny pakiet.

Rodzaje bibliotek po stronie klienta:

1. Dotyka DOM
2. Nie dotyka DOM

W przypadku pierwszego rodzaju (widżety interfejsu użytkownika itp.) Zazwyczaj zakłada się, że jQuery jest obecny. Możesz także napisać „Biblioteka DOM agnostyczna” i pracować z mniej popularnymi, ale nie zawracam sobie tym głowy.

Z drugim rodzajem. Po pierwsze, nie rób z niego wtyczki jQuery, na przykład „wtyczka jQuery cookie” jest śmieszna, ale taka biblioteka faktycznie istnieje.

Oba rodzaje mogą nie mieć zależności, małe zależności lub ogromne zależności - przy czym biblioteka domowa nie liczy się jako zależność w tym sensie. W przypadku pierwszych 2 po prostu połączysz je w zakresie biblioteki i nie będziesz się martwić o możliwe powielanie. Na przykład jQuery łączy funkcję wewnętrzną isArrayLike, nawet jeśli użytkownik może już mieć swoją własną z biblioteki losowych pasków narzędzi.

Mam tylko jedno osobiste doświadczenie z ogromną zależnością przy tworzeniu biblioteki (właściwie języka) - moment.js. W tym przypadku dostarczę 2 kompilacje, jedną z moment.js połączoną, a drugą bez, w której użytkownik jest odpowiedzialny za jej włączenie. Nie wiem jednak, czy to dobre rozwiązanie.

I tak, w każdym przypadku przyjmuje się podejście jQuery polegające na zbudowaniu jednego końcowego dużego pliku, który po prostu działa. Na dole znajduje się płyta modułu (wymaga wykrycia / AMD / global itp.).