Come modulare e impacchettare una libreria Javascript lato client oggi?

Sono stato al passo con il moderno ecosistema JS lato client e ho letto su CommonJS e AMD (inclusi gli strumenti associati: browserify, requestjs, onejs, jam, dozzine di altri). Se sto scrivendo una libreria Javascript, come posso modulare / impacchettarla in modo tale che possa essere ampiamente accessibile (idealmente dagli utenti che giurano su CommonJS, AMD e soprattutto nessuno dei due)?

Le librerie popolari come jQuery sembrano usare solo la concatenazione di file della vecchia scuola per costruirsi e rilevare dinamicamente se dovrebbe scrivere in un exportscontesto globale. Attualmente sto facendo la stessa cosa, ma il principale svantaggio è che se (a differenza di jQuery) dipendo da alcune librerie, è bello non dover chiedere agli utenti di pre-includere manualmente il set transitivo. (Anche se al momento ho solo due dipendenze.) E ovviamente l'inquinamento dello spazio dei nomi globale.

O forse è più pulito generare più versioni della mia libreria, per ogni contesto?

Mi sto anche chiedendo del packaging e dell'editoria. Esistono diversi sistemi, ma credo che quello principale sia il bower, che è facile da gestire poiché tutto ciò che fa è recuperare. Tuttavia, mi chiedo se dovrei anche scegliere come target altri sistemi di pacchetti come componente (che richiede CommonJS).

Ci sono altri aspetti rilevanti di cui dovrei essere a conoscenza? Ci sono dei buoni progetti da seguire per tutto questo?

Ho sempre usato i file build ma da quando ho iniziato il mio primo progetto nodejs ho iniziato a usare browserify . Con browerify e altre librerie simili il tuo codice è il tuo file di build. Sto sfruttando una libreria client e server che può essere eseguita su entrambi ma può funzionare anche con un codice puramente client. Per riassumere, browserify ti offre tutti i vantaggi della scrittura del codice nel nodo (nessuna funzione anon per evitare globali, npm, semplici requisiti) e ti consente di impacchettare quel codice da eseguire sul client con un solo comando e caricare un solo file.

Con browserify puoi fare qualcosa di simile (chiamato 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

Produrrebbe qualcosa come:

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

Il file che definiresti potrebbe includere tutte le librerie di terze parti incluse e non scontrarsi con nessuno dei tuoi sviluppatori che lo utilizzano.

- Modifica in risposta al commento (e una completa mancanza sulla domanda)

Immagino che dipenderebbe dalle tue dipendenze e da quanto tempo vuoi dedicare assicurandoti che funzionino su tutte le versioni e librerie. Se le tue dipendenze sono comuni e seguono la stessa API da una versione all'altra, potresti seguire il percorso Backbone e richiedere all'utente di avere $ e _. Suggerirei di inserire le librerie più oscure come parte del file in bundle. Le opzioni non devono nemmeno essere tagliate e asciugate. Potresti offrire un pacchetto predefinito o compilare il tuo pacchetto.

Tipi di librerie lato client:

1. Tocca DOM
2. Non tocca DOM

Con il primo tipo (widget UI, ecc.), In genere supporrete che jQuery sia presente. Puoi anche scrivere "agnostico della libreria DOM" e farlo funzionare anche con quelli meno popolari, ma non mi preoccupo.

Con il secondo tipo. Prima di tutto, non renderlo un plug-in jQuery, ad esempio "plug-in cookie jQuery" è ridicolo ma esiste effettivamente una libreria del genere.

Entrambi questi tipi potrebbero non avere dipendenze, piccole dipendenze o enormi dipendenze - con una libreria dom che non conta come una dipendenza in questo senso. Con i primi 2, li concateneresti all'interno del tuo ambito di libreria e non ti preoccupare di possibili duplicazioni. Ad esempio, jQuery concatena una isArrayLikefunzione interna , anche se l'utente potrebbe avere il proprio già incluso in una libreria casuale di utility.

Ho solo un'esperienza personale con un'enorme dipendenza nello sviluppo di una biblioteca (in realtà una lingua) - moment.js. In questo caso, fornirei 2 build, una con moment.js concatenata e una senza, in cui l'utente è responsabile di includerla. Non so se questa sia una buona soluzione.

E sì, in ogni caso, viene adottato l'approccio jQuery per la creazione di un grosso file finale che funzioni. Ha il modulo boilerplate in basso (richiesta / rilevamento AMD / globale ecc.).