Per nodejs quali sono le migliori pratiche di progettazione per i moduli nativi che condividono le dipendenze?

Ci sono essenzialmente due modi per farlo. Quale è adatto a te dipende da cosa vuoi ottenere.

1. Caso 1: A, B e C sono vagamente correlati, cioè se ad es. B può essere usato senza A e C. Avere A e / o C disponibili estenderebbe la funzionalità di B.

2. Caso 2: A, B e C sono strettamente correlati e alcune parti di A, B o C si basano sull'esistenza di A, B o C. Insieme formano un'unità logica.

Se il caso 1 si adatta allo scopo dei tuoi progetti, allora vuoi costruire moduli di nodi separati e fare in modo che l'utente finale inserisca questi moduli e li usi a volontà.

Se il caso 2 si adatta meglio, allora vuoi compilare A, B e C in un modulo, ad es. ABC. Puoi ancora strutturare il codice sorgente (e l'API esportata) del modulo ABC secondo A, B e C.

Costruire tre moduli separati e collegarli dinamicamente non ha molto senso. Infatti, sono collegati dinamicamente (per nodo) quando vengono importati ( require 'd) nel nodo-terra. Collegarli staticamente in modo statico potrebbe avere più senso, il bus è essenzialmente un modo più semplice di realizzare "soluzione 2" (producendo un singolo modulo).

Modifica:

Se A, B e C sono tre moduli che non sono stati creati da te, allora hai a che fare con una gerarchia. Come lo spieghi nella tua ipotesi, la gerarchia della dipendenza è:

B --requires--> A
C --requires--> B
C --requires--> A

Quindi A potrebbe essere "posseduto" da B, e B potrebbe essere di proprietà di C. Se si scrive C, quindi fornire un'API rivolta all'utente con un punto di ingresso in JavaScript, dove si require i tre moduli. Compilare A, B e C come moduli separati e farli vivere "dentro" il modulo composto. La struttura del file system potrebbe essere simile a questa:

foo/          # Your compound module
foo/index.js  # require('./_A'), require('./_B'), require('./_C')
foo/_A.node
foo/_B.node
foo/_C.node

Poiché il codice in _C.node richiede l'implementazione di determinati simboli (ad esempio i simboli dipendenti da A e B), sarà necessario caricare i moduli in ordine.

Nota che non l'ho ancora testato, ma in teoria dovrebbe funzionare.

Promosso da rsms Mi piacerebbe condividere l'architettura con cui ora ho risposto originariamente / condiviso qui su stackoverflow .

What's the best way to create common native source code packages that other node modules can rely on?

... Ho una risposta per la costruzione di librerie riutilizzabili con moduli nativi witlinh.

Sto usando git submodules per tutti i moduli di nodi nativi indipendenti e ho aggiunto una definizione di preprocessore condizionale per ciascuno dei loro file wscript o binding.gyp per specificare se generare o meno un modulo .node di oggetti condivisi.

Inoltre userò questo nuovo pacchetto per facilitare il debugging o la riscrittura delle sezioni di codice (non posso impiegare troppo tempo per il debug dell'utilizzo di diverse librerie remote).

in wscript o binding.gyp

  flags = ['-D_NAME_NODE_MODULE', '-O3', '-Wall', '-D_FILE_OFFSET_BITS=64', '-D_LARGEFILE_SOURCE', '-msse2']

quindi in un file di inizializzazione

#ifdef _NAME_NODE_MODULE

extern "C" {
  static void init(Handle<Object> target) {
    HandleScope scope;
    NODE_SET_METHOD(target, "someFunction", someFunction);
  }

  NODE_MODULE(moduleName, init);
}

#endif

In questo modo un modulo nativo del nodo viene aggiunto solo quando viene impostato il flag. Altrimenti può essere collegato normalmente (come in un altro modulo nodo).