: Combina diversi progetti JavaScript (modulari)

Question

Vorrei creare un'architettura pulita per il mio progetto JavaScript. Il progetto consiste in un server Node.js e due front-end Angular.js separati con scopi diversi. Per costruire i front-end io uso un build personalizzato per grunt ciascuno. La build risulta in un singolo file HTML per progetto e due file CSS e JavaScript miniati/migliorati. Ogni front-end viene quindi eseguito su una versione minima separata di un server Node (serve solo i file statici).

Finora, così chiaro. L'obiettivo è ora di rendere possibile aggiungere moduli plugin a ciascuno dei tre progetti principali. Un modulo dovrebbe estendere il codice JavaScript di uno dei progetti. Questo significa ad es. in caso di un front-end per aggiungere un modulo angolare aggiuntivo alla configurazione angolare. So già dove e come aggiungere il codice del modulo angolare nell'app principale.

Il problema è ora: come si crea un processo di creazione ragionevole su più progetti che dipende anche dai moduli di plugin? Ho trovato due soluzioni.

1. È possibile aggiungere un plug-in come dipendenza NPM a uno dei progetti principali. Questo ha tuttavia lo svantaggio, che ogni cambiamento nel modulo deve essere trasferito su NPM e non è molto conveniente sviluppare il modulo plugin in questo modo. Un plugin non è eseguibile da solo.
2. Potrei avere una lista di plugin all'interno del Gruntfile di uno dei progetti principali. Questo elenco conterrà percorsi di file locali ai moduli. Nella build del modulo core, verranno eseguite le build dei plug-in. Ciò includerebbe comunque la visione dei cambiamenti dei file creati dei plugin. È una soluzione sporca.
3. Potrei avere un altro progetto che contenga dipendenze dal progetto principale e da tutti i plugin e lo costruisca tutti insieme. La questione su come aggiungere la dipendenza rimane (caso 1 o 2)

Come risolverebbe questo problema?

Answer 1

Di solito faccio esattamente quello che hai descritto in 1. Ma io uso le dipendenze locali che saranno concatenate dalla mia catena di costruzione.

npm install ~/project_root/sub_project --save-dev 

in questo modo non è necessario spingerlo tutto il tempo. è sufficiente eliminare la cartella node_module/sub_project ed eseguire npm install nuovamente all'interno della catena di build.

con browserify puoi quindi aggiungere le tue dipendenze al tuo progetto angolare.

Un plug-in non è eseguibile singolarmente.

Generalmente sviluppo i miei servizi o direttive come normali classi JavaScript e li avvolgo con angolazione.

var Service = require("./path/to/service.js") 
module.exports = [function() { 
    return { 
     restrict: 'AC', 
     link: function($scope, $element) { 
      var someService = new Service(); 
      $scope.$watch("whatever",function(value){ 
       service.doSomething(); 
      }) 
     } 
    }; 
}]; 

In questo modo è possibile eseguirli e testarli indipendentemente da angolari. Ciò risulta vantaggioso anche quando si lavora con WebWorkers. Dal momento che non possono realmente (completamente) essere usati con 1.X angolare.

Answer 2

Stai aggiungendo una complessità non necessaria al tuo progetto MEAN.
Perché concatenate le due parti html via grunt ???
Si dovrebbe usare l'architettura SPA di AngularJS, c'è una ragione per cui l'hanno adottata .. uno di loro non è in esecuzione in tali problemi.
Invece di concatenare i file, è sufficiente configurare gli stati della SPA per chiamare il modello parziale richiesto da un file html.THAT'S IT!
E utilizzare i servizi Web sul back-end (penso che lo farai) in questo modo sei indipendente dall'origine dei dati poiché stai utilizzando l'URI indipendentemente dal server da cui proviene.
Informazioni sulle dipendenze, usereste npm senza soluzione di continuità sul fronte o sul retro con il flag --save per aggiungerli al file package.json e quindi copiarlo nelle rispettive directory dirs e npm install.
Ma io davvero non vedo dove stai andando con tutto questo, se spiegassi un po 'di più sui requisiti funzionali che potrebbero aiutare a capire.

Answer 3

Ho avuto un problema simile qualche mese fa. L'installazione di dipendenze dinamiche potrebbe essere risolta in modo abbastanza semplice poiché si ha familiarità con lo streaming di sistemi di costruzione come Grunt o Gulp.

1. Si può assegnare una proprietà all'interno della vostra package.json come dipendenze o devdependencies che conterrà tutte le informazioni aggiuntive necessarie, bower.json o anche un file JSON personalizzato farà il trucco troppo. Preferisco manifesti di imballaggio NPM o manifesti di Bower in quanto forniscono un punto di ingresso valido per ogni modulo.
2. Utilizzando grunt-auto-install è possibile installare in modo dinamico eventuali dipendenze aggiuntive del modulo per il processo di costruzione, quelle che è possibile analizzare dal file principale del progetto.
3. Utilizzando la proprietà main di ogni modulo da ogni pacchetto aggiuntivo. Json verrà fornito un elenco di file per inizializzare un'attività di ugolazione o concatenazione.

Answer 4

IMHO, non è che legate al lavoro task manager (aka GULP, grugnito o addirittura webpack, ma non importa qui). La comunità va in un posto in cui possiedi molti (relativamente) minuscoli moduli di nodi che fanno una cosa e la fanno bene, quindi è abbastanza connessa al tuo primo suggerimento.

Un VCS pronti contro termine potrebbe essere la seguente struttura:

my-repo/ 
    package-1/ 
    package.json 
    package-2/ 
    package.json 
    package-3/ 
    package.json 
    ... 

... allora lavorare con npm link per rendere i collegamenti simbolici all'interno dei moduli stessi, in questo modo non c'è bisogno di pubblicare i moduli per ottenere gli aggiornamenti .

C'è un nuovo pacchetto chiamato lerna che fa esattamente questo npm link thingy, automaticamente (rileva il grafico delle dipendenze nei moduli "locali" e crea un collegamento tra di loro), tutto ciò che devi fare è seguire la loro struttura. Inoltre, rende la pubblicazione intelligente, è possibile eseguire comandi in tutti i pacchetti e molte altre cose correlate.

Babel, React sono ottimi esempi di questo modulo-separazione-di-preoccupazione. Babel lavora con lerna per automatizzare il collegamento tra i pacchetti, here are their reasons to have a monorepo.