Le migliori pratiche per aggiungere funzionalità di generazione Node.JS a un progetto non Nodo

Question

Le migliori pratiche per aggiungere funzionalità di generazione Node.JS a un progetto non Nodo

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

1

L'utilizzo principale di Node.JS è ovviamente uno stack completo del server, e l'ho usato in questo modo con grande successo.

Tuttavia, un certo numero di pacchetti NPM utili e interessanti si occupano di cose come il traspiling di un linguaggio stilistico, l'aggiunta di informazioni di digitazione a JavaScript senza tipografia, l'esecuzione di test di unità JavaScript, persino un sistema di compilazione "piped" come Gulp.

Attualmente, lavoro su un progetto che utilizza Tomcat e viene scritto principalmente in Java. Le utilità Java e Ant si sono sentite un po 'limitanti in termini di interazione con i nostri file JavaScript durante la creazione / test, quindi sto esaminando la possibilità di aggiungere una dipendenza su NodeJS e impostare le dipendenze di compilazione.

Perché dovrei farlo?

Voglio distintamente evitare di aggiungere dipendenze "perché sono interessanti". Voglio solo aggiungere pacchetti Node per scenari in cui non è fattibile, o addirittura deprecato, per risolvere particolari problemi usando programmi basati su Java (es. Ant).

Un esempio: la nostra libreria di widget JavaScript, Dojo, ha dichiarato che non supporteranno l'esecuzione di build Dojo tramite Java per molto più tempo, essendosi ampiamente spostati su build Node. Inoltre, alcuni toolkit di compressione CSS eseguiti con Java hanno smesso di essere gestiti a favore di quelli come LESS. Esistono anche strumenti di sviluppo come i test delle unità JavaScript o i tipi TypeScript che vorremmo considerare per rendere lo sviluppo più affidabile. L'utilizzo di un gestore delle dipendenze potrebbe anche aiutarci a progettare una soluzione in cui non abbiamo l'intero codice sorgente di Dojo impegnato nel nostro repository.

La domanda: layout del progetto corretto e potenziali insidie

Quali sarebbero le pratiche affidabili da seguire se voglio utilizzare il nodo come dipendenza build / test / sviluppo, ma non lo richiedono per l'app finale, pacchettizzata (e pro / contro di approcci diversi)? In questo scenario, ha davvero senso includere un package.json nella gerarchia del progetto root? Le attività di compilazione relative ai nodi devono essere invocate tramite Ant o ha senso richiedere azioni di comando separate per invocarle? In quali scenari gli sviluppatori / costruttori di macchine devono eseguire "npm install" e devono sempre essere automatizzati?

Se basati sull'esperienza le persone tendono a trovare che la risposta a queste domande non ha importanza, è anche una risposta utile - ma sto chiedendo di sperare che l'esperienza eviti alcune insidie del design.

builds node.js project-structure

posta Katana314 21.01.2016 - 19:07

fonte

2 risposte

Leggi altre domande sui tag builds node.js project-structure

Come vedere quali parti del tuo codice vengono eseguite più spesso? Come ridurre al minimo il numero di query del database in un'API GeoJson (di paesi e aree più piccole) con dati personalizzati?

score 0 · Answer 1

Avere entrambi condividono la stessa radice va bene. Apache Freemarker Docgen utilizza questa struttura. Il richiamo della build JavaScript dall'interno della build Java è lo standard. L'esecuzione di npm install può essere decisa a livello di codice dalla build Java. Ad esempio, in Maven:

<plugin>
    <groupId>com.github.eirslett</groupId>
    <artifactId>frontend-maven-plugin</artifactId>
    <version>0.0.27</version>

    <executions>

      <execution>
        <id>install node and npm</id>
        <goals>
          <goal>install-node-and-npm</goal>
        </goals>
        <configuration>
          <nodeVersion>v4.2.1</nodeVersion>
          <npmVersion>3.5.3</npmVersion>
        </configuration>
      </execution>

      <execution>
        <id>npm install</id>
        <goals>
          <goal>npm</goal>
        </goals>
        <configuration>
          <arguments>install</arguments>
        </configuration>
      </execution>

      <execution>
        <id>npm run build</id>
        <goals>
          <goal>npm</goal>
        </goals>
        <configuration>
          <arguments>run build</arguments>
        </configuration>
      </execution>

    </executions>
</plugin>

Riferimenti

score 0 · Answer 2

Mi trovo a usare il Nodo per miscellanea correlata alla costruzione abbastanza frequentemente, anche per progetti non Node come C ++ e altri. Fornisce l'immediatezza dello scripting della shell in un programmatore meno arcano, più digeribile rispetto alla media, e probabilmente più pacchetto multipiattaforma rispetto agli script di compilazione convenzionali. Ciò sarebbe vero anche senza l'ecosistema Grunt / Gulp, che fornisce un modo dichiarativo di strutturazione di build o di attività correlate all'implementazione ed è, a mio parere, sottoutilizzato a questo scopo (come build sidekick) data l'utilità del sistema rispetto alle complessità di shell o la maggior parte dei sistemi di build proprietari.

Lascia che ti dia un esempio.

In uno dei miei progetti di gioco, devo dare il calcio a un sacco di codice C ++ e C # in varie configurazioni. Le risorse devono essere massaggiate, i file di testo devono essere analizzati e tutto questo in modi estremamente specifici. Ora, potrei aver scelto di farlo con i vari strumenti proprietari o strumenti specifici della lingua (Visual Studio + Unity / Unreal, ad esempio). Invece, gestisco tutto con il nodo. Questo sembra più pulito e accessibile. So che può prendere le stesse risorse di build ed eseguire la mia build su OS X, Linux o Windows, senza preoccuparsi di differenze oscure in shell, sistemi di compilazione o IDE.

Questo non significa fare tutto nel modo più difficile. Cerco di consentire al mio normale ecosistema di sviluppo di gestire le attività di compilazione in in qualsiasi modo abbia senso per la lingua e l'ambiente . Ma sono disposto al 100% a utilizzare Node per fare lo spackle nel resto, e credo che tu possa difendere questa decisione da un punto di vista tecnico abbastanza vigorosamente.

E comunque, a chi non piace lavorare con Node? Vivi un po '!