Come modularizzare e impacchettare una libreria Javascript sul lato client oggi?

Question

Come modularizzare e impacchettare una libreria Javascript sul lato client oggi?

#1 da (2 voti)
#2 da (0 voti)

11

Mi sono ritrovato con il moderno ecosistema JS lato client e ho letto su CommonJS e AMD (inclusi strumenti associati: browserify, requirejs, onejs, jam, dozzine di altri). Se sto scrivendo una libreria Javascript, come faccio a modularizzarlo / impacchettarlo in modo tale che possa essere più accessibile (idealmente dagli utenti che giurano su CommonJS, AMD e soprattutto nessuno dei due)?

Le librerie popolari come jQuery sembrano utilizzare solo la concatenazione di file vecchia scuola per costruirsi e rilevare dinamicamente se scrivere in exports o nel contesto globale. Al momento sto facendo la stessa cosa, ma lo svantaggio principale è che se io (a differenza di jQuery) dipende 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 naturalmente l'inquinamento dello spazio dei nomi globale.

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

Mi sto anche interrogando sul packaging e la pubblicazione. Esistono diversi sistemi, ma credo che il principale sia il bower, che è facile da gestire poiché tutto ciò che fa è recuperare. Tuttavia, mi chiedo se dovrei prendere di mira anche altri sistemi di pacchetti come il componente (che richiede CommonJS).

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

javascript packages modules

posta Yang 16.05.2013 - 18:46

fonte

2 risposte

Leggi altre domande sui tag javascript packages modules

Quanto dovrebbe essere facile utilizzare un framework di sviluppo linguistico? Genera a caso un grafico diretto su una griglia

score 2 · Answer 1

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

Con browserify puoi fare qualcosa come (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 del tipo:

[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 tue librerie di terze parti e non scontrarsi con nessuno dei tuoi sviluppatori che lo utilizza.

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

Immagino che ciò dipenda dalle tue dipendenze e da quanto tempo vuoi spendere facendo in modo che funzionino su tutte le versioni e le librerie. Se le tue dipendenze sono comuni e segui la stessa API dalla versione alla versione, potresti fare il percorso Backbone e richiedere semplicemente all'utente di avere $ e _. Suggerirei di inserire le librerie più oscure come parte del file in bundle. Le opzioni non devono essere né tagliate né asciutte. Potresti offrire un pre-costruito o creare il tuo pacchetto.

score 0 · Answer 2

Tipi di librerie client-side:

Tocca DOM
Non tocca DOM

Con il primo tipo (widget dell'interfaccia utente, ecc.), in genere si presuppone che jQuery sia presente. Puoi anche scrivi "libreria DOM agnostica" e fallo funzionare anche con quelli meno popolari, ma non mi preoccupo.

Con il secondo tipo. Prima di tutto, non farne un plugin jQuery, ad esempio "plugin per jQuery cookie" è ridicolo ma tale libreria esiste realmente.

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, devi semplicemente concatenarli all'interno dell'ambito della tua biblioteca e non preoccuparti di possibili duplicazioni. Ad esempio, jQuery concatena una funzione interna isArrayLike , anche se l'utente potrebbe avere il proprio già incluso in una libreria di utilità casuali.

Ho solo un'esperienza personale con un'enorme dipendenza durante lo sviluppo di una libreria (in realtà una lingua) - moment.js . In questo caso fornirei 2 build, uno con moment.js concatenato e uno senza, dove l'utente è responsabile per includerlo. Non so se questa è una buona soluzione però.

E sì, in ogni caso, l'approccio jQuery di costruire un file finale che funziona è preso. Ha la piastra del modulo in basso (richiede / AMD / rilevamento globale ecc.)