Organizzazione delle dipendenze di package.json in applicazioni universali/isomorfe

Question

Con React e altri framework è ora comune utilizzare npm e package.json per installare le librerie che verranno utilizzate sul frontend. Se stai sviluppando un'applicazione universale/isomorfa, questo introduce il problema che le dipendenze per il frontend e il backend sono memorizzate nello stesso file, creando un elenco di dipendenze enorme.

Se si utilizza npm --save/- save-dev, entrambi i tipi di dipendenze (frontend, backend) diventano misti ed è difficile conoscerli, senza andare uno per uno, quale viene utilizzato dove.

Oltre all'ordinamento e alla gestione manuale delle dipendenze, esiste un modo per mantenere ordinato l'elenco? Quali sono le tue strategie per gestire le liste di dipendenze?

Answer 1

In un'applicazione universale/isomorfa, avrete probabilmente poche dipendenze che sono puramente frontend o puramente backend; la maggior parte delle dipendenze sono condivise.

Un'opzione che mi viene in mente è quello di utilizzare più di un package.json:

• uno per le dipendenze isomorfe (reagire, Redux, etc.) e le dipendenze di utilità come il sistema di generazione (Babel, webpack, ecc .), corridori compito (gulp, cross-env), test (karma) e così via;
• uno per le dipendenze di frontend pure;
• uno per le dipendenze del back-end puro.

Non ho usato quella struttura me stesso, e non sono sicuro che sarà più gestibile che un singolo package.json, perché dovrete gestire più cose (e se si aggiunge NPM-shrinkwrap a quello, è due volte più file).

Answer 2

Sono assolutamente d'accordo con la risposta sompylasar e voglio espandermi un po 'oltre. Penso davvero che due diversi file package.json sono l'unico modo per farlo.

Pensa al frontend e al backend come due diverse applicazioni. Anche in due ambienti molto diversi tra loro, e in quanto tale anche le esigenze di confezionamento e di costruzione saranno diverse.

L'intero punto di npm è di avere dipendenze isolate per pacchetto. Stai andando contro questo condividendo la tua lista delle dipendenze con due applicazioni completamente indipendenti (frontend e backend).

Immaginate di assumere nuovi sviluppatori front-end e di voler aggiornare alcuni pacchetti front-end, ora devono andare avanti e capire come eseguire e testare il back-end, perché potrebbero violare qualcosa.

Potrebbe sembrare un po 'più ingombrante gestire due file package.json all'inizio, ma questo tipo di isolamento manterrà la tua app sana man mano che cresce.

Come tale, vorrei raccomandare una struttura in cui si hanno due cartelle di pari livello con ciascuno il proprio package.json. Esattamente come vuoi strutturare che dipende da te.

Se si dispone di una logica di business principale che si desidera condividere tra frontend e backend, è possibile inserirla in un pacchetto npm separato, che può quindi fare riferimento al pacchetto backend e frontend come dipendenza. È possibile utilizzare npm link per sviluppare contemporaneamente la stessa versione nella parte anteriore e posteriore per il comfort di sviluppo.