Come rendere node.js richiede assoluto? (invece di relativo)

Mi piacerebbe richiedere i miei file sempre dalla radice del mio progetto e non rispetto al modulo corrente.

Ad esempio se si guarda https://github.com/visionmedia/express/blob/2820f2227de0229c5d7f28009aa432f9f3a7b5f9/examples/downloads/app.js linea 6 vedrai

express = require('../../') 

Questo è veramente male IMO. Immagina che mi piacerebbe mettere tutti i miei esempi più vicini alla radice solo di un livello. Ciò sarebbe imansible, perché dovrei aggiornare più di 30 esempi e molte volte all’interno di ciascun esempio. A questa:

 express = require('../') 

La mia soluzione sarebbe quella di avere un caso speciale per root: se una stringa inizia con $ allora è relativa alla cartella radice del progetto.

Qualsiasi aiuto è apprezzato, grazie

Aggiornamento 2

Ora sto usando require.js che ti permette di scrivere in un modo e funziona sia sul client che sul server. Require.js consente anche di creare percorsi personalizzati. «

Aggiornamento 3

Ora mi sono spostato su webpack + gulp e uso enhanced-require per gestire i moduli sul lato server. Vedi qui la spiegazione: http://hackhat.com/p/110/module-loader-webpack-vs-requirejs-vs-browserify/

E che mi dici di:

 var myModule = require.main.require('./path/to/module'); 

Richiede il file come se fosse richiesto dal file js principale, quindi funziona abbastanza bene finché il tuo file js principale è alla radice del tuo progetto … e questo è qualcosa che apprezzo.

C’è una sezione molto interessante nel Manuale di Browserify :

evitando ../../../../../../ ..

Non tutto in un’applicazione appartiene propriamente al pubblico npm e il sovraccarico nell’impostazione di un npm privato o repo git è ancora piuttosto ampio in molti casi. Ecco alcuni approcci per evitare il problema dei percorsi relativi ../../../../../../../ .

node_modules

A volte le persone si oppongono a mettere i moduli specifici dell’applicazione in node_modules perché non è ovvio come controllare i moduli interni senza nemmeno controllare i moduli di terze parti da npm.

La risposta è abbastanza semplice! Se hai un file node_modules che ignora node_modules :

 node_modules 

Puoi semplicemente aggiungere un’eccezione con ! per ciascuno dei moduli dell’applicazione interna:

 node_modules/* !node_modules/foo !node_modules/bar 

Si noti che non è ansible annullare l’assegnazione di una sottodirectory, se il genitore è già stato ignorato. Quindi, invece di ignorare node_modules , devi ignorare ogni directory all’interno di node_modules con il trucco node_modules/* , e quindi puoi aggiungere le tue eccezioni.

Ora ovunque nella tua applicazione sarai in grado di require('foo') o require('bar') senza avere un percorso relativo molto grande e fragile.

Se hai molti moduli e vuoi tenerli più separati dai moduli di terze parti installati da npm, puoi metterli tutti in una directory in node_modules come node_modules/app :

 node_modules/app/foo node_modules/app/bar 

Ora potrai require('app/foo') o require('app/bar') da qualsiasi punto della tua applicazione.

Nel tuo .gitignore , aggiungi un’eccezione per node_modules/app :

 node_modules/* !node_modules/app 

Se la propria applicazione aveva trasformazioni configurate in package.json, sarà necessario creare un pacchetto separato.json con il proprio campo di trasformazione nella node_modules/foo o node_modules/app/foo component perché le trasformazioni non si applicano ai limiti del modulo. Ciò renderà i moduli più solidi rispetto alle modifiche alla configurazione dell’applicazione e sarà più semplice riutilizzare i pacchetti indipendentemente dall’applicazione.

link simbolico

Un altro trucco pratico se si sta lavorando su un’applicazione in cui è ansible creare collegamenti simbolici e non è necessario supportare Windows è quello di colbind simbolicamente una lib/ o app/ cartella in node_modules . Dalla radice del progetto, fare:

 ln -s ../lib node_modules/app 

e ora da qualsiasi punto del tuo progetto sarai in grado di richiedere i file in lib/ facendo require('app/foo.js') per ottenere lib/foo.js

percorsi personalizzati

Potresti vedere alcuni luoghi parlare dell’utilizzo della variabile d’ambiente $NODE_PATH o opts.paths per aggiungere directory per il nodo e browserify per cercare i moduli.

A differenza della maggior parte delle altre piattaforms, l’utilizzo di una matrice di directory di percorso in stile shell con $NODE_PATH non è favorevole nel nodo rispetto all’utilizzo effettivo della directory node_modules .

Questo perché la tua applicazione è più strettamente connessa alla configurazione di un ambiente di runtime, quindi ci sono più parti mobili e l’applicazione funzionerà solo quando il tuo ambiente è configurato correttamente.

node e browserify supportano entrambi ma scoraggiano l’utilizzo di $NODE_PATH .

Mi piace creare una nuova cartella node_modules per il codice condiviso, quindi lasciare che il nodo e richieda ciò che sa fare meglio.

per esempio:

 - node_modules // => these are loaded from your package.json - app - node_modules // => add node-style modules - helper.js - models - user - car - package.json - .gitignore 

Ad esempio, se sei in car/index.js puoi require('helper') e il nodo lo troverà!

Come funzionano node_modules

nodo ha un algoritmo intelligente per risolvere i moduli che è unico tra le piattaforms concorrenti.

Se require('./foo.js') da /beep/boop/bar.js , il nodo cercherà ./foo.js in /beep/boop/foo.js . I percorsi che iniziano con ./ o ../ sono sempre locali per il file che richiede require() .

Se tuttavia si richiede un nome non relativo come require('xyz') da /beep/boop/foo.js , il nodo ricerca questi percorsi in ordine, fermandosi alla prima corrispondenza e generando un errore se non viene trovato nulla:

 /beep/boop/node_modules/xyz /beep/node_modules/xyz /node_modules/xyz 

Per ogni directory xyz esistente, il nodo cercherà prima un xyz/package.json per vedere se esiste un campo "main" . Il campo "main" definisce quale file dovrebbe prendere in carico se si require() il percorso della directory.

Ad esempio, se /beep/node_modules/xyz è la prima corrispondenza e /beep/node_modules/xyz/package.json ha:

 { "name": "xyz", "version": "1.2.3", "main": "lib/abc.js" } 

quindi le esportazioni da /beep/node_modules/xyz/lib/abc.js verranno restituite da require('xyz') .

Se non ci sono package.json o nessun campo "main" , si assume index.js :

 /beep/node_modules/xyz/index.js 

La grande immagine

Sembra “davvero brutto” ma dargli tempo. È, infatti, davvero buono. I require() espliciti require() forniscono una totale trasparenza e facilità di comprensione che è come una boccata d’aria fresca durante un ciclo di vita del progetto.

Pensaci in questo modo: stai leggendo un esempio, immergendo le dita dei piedi in Node.js e hai deciso che è “davvero IMO male”. Siete i leader della community Node.js, persone che hanno registrato più ore di scrittura e manutenzione delle applicazioni Node.js di chiunque altro. Qual è la possibilità che l’autore abbia commesso un tale errore da principiante? (E sono d’accordo, dal mio background in Ruby e Python, sembra in un primo momento un disastro.)

C’è un sacco di clamore e contro-hype che circonda Node.js. Ma quando la polvere si depositerà, riconosceremo che i moduli espliciti e i pacchetti “locali” sono stati un importante motore di adozione.

Il caso comune

Naturalmente, node_modules dalla directory corrente, quindi viene cercato il genitore, poi nonno, bisnonno, ecc. Quindi i pacchetti che hai installato funzionano già in questo modo. Di solito puoi require("express") da qualsiasi punto del tuo progetto e funziona perfettamente.

Se ti ritrovi a caricare file comuni dalla radice del tuo progetto (forse perché sono funzioni di utilità comuni), allora è un grande indizio che è ora di creare un pacchetto. I pacchetti sono molto semplici: sposta i tuoi file in node_modules/ e metti qui un package.json . Ecco! Tutto in quello spazio dei nomi è accessibile dal tuo intero progetto. I pacchetti sono il modo corretto per ottenere il tuo codice in uno spazio dei nomi globale.

Altre soluzioni alternative

Personalmente non uso queste tecniche, ma rispondono alla tua domanda e, naturalmente, conosci la tua situazione meglio di me.

È ansible impostare $NODE_PATH nella root del progetto. Quella directory verrà ricercata quando require() .

Successivamente, potresti compromettere e richiedere un file locale comune da tutti i tuoi esempi. Quel file comune semplicemente ri-esporta il vero file nella directory di grandparent.

esempi / download / app.js (e molti altri come questo)

 var express = require('./express') 

Esempi / download / express.js

 module.exports = require('../../') 

Ora, quando si riposizionano quei file, il caso peggiore è la risoluzione del modulo di uno shim .

Dai un’occhiata a node-rfr .

È così semplice:

 var rfr = require('rfr'); var myModule = rfr('projectSubDir/myModule'); 

IMHO, il modo più semplice è definire la propria funzione come parte dell’object GLOBAL . Crea projRequire.js nella root del tuo progetto con i seguenti contenuti:

 var projectDir = __dirname; module.exports = GLOBAL.projRequire = function(module) { return require(projectDir + module); } 

Nel tuo file principale prima di require uno qualsiasi dei moduli specifici del progetto:

 // init projRequire require('./projRequire'); 

Dopo quello che segue lavori per me:

 // main file projRequire('/lib/lol'); // index.js at projectDir/lib/lol/index.js console.log('Ok'); 

@Totty, ho trovato un’altra soluzione, che potrebbe funzionare per il caso che hai descritto nei commenti. La descrizione sarà tl;dr , quindi è meglio mostrare una foto con la struttura del mio progetto di test .

Io uso process.cwd() nei miei progetti. Per esempio:

 var Foo = require(process.cwd() + '/common/foo.js'); 

Potrebbe valere la pena notare che ciò comporterà la require un percorso assoluto, sebbene debba ancora incorrere in problemi con questo.

C’è una buona discussione di questo problema qui .

Mi sono imbattuto nello stesso problema architettonico: volevo un modo per dare alla mia applicazione più spazio per i nomi di organizzazione e interni, senza:

  • miscelazione di moduli applicativi con dipendenze esterne o fastidio con repository npm privati ​​per codice specifico dell’applicazione
  • usando le esigenze relative, che rendono più difficile il refactoring e la comprensione
  • usando i collegamenti simbolici o cambiando il percorso del nodo, che può oscurare le posizioni della fonte e non giocare bene con il controllo del codice sorgente

Alla fine, ho deciso di organizzare il mio codice usando le convenzioni di denominazione dei file piuttosto che le directory. Una struttura sarebbe simile a qualcosa:

  • NPM-shrinkwrap.json
  • package.json
  • node_modules
  • src
    • app.js
    • app.config.js
    • app.models.bar.js
    • app.models.foo.js
    • app.web.js
    • app.web.routes.js

Quindi nel codice:

 var app_config = require('./app.config'); var app_models_foo = require('./app.models.foo'); 

o semplicemente

 var config = require('./app.config'); var foo = require('./app.models.foo'); 

e dipendenze esterne sono disponibili da node_modules come al solito:

 var express = require('express'); 

In questo modo, tutto il codice dell’applicazione è organizzato gerarchicamente in moduli e disponibile per tutti gli altri codici relativi alla root dell’applicazione.

Lo svantaggio principale è ovviamente che in un browser di file non è ansible espandere / comprimere l’albero come se fosse effettivamente organizzato in directory. Ma mi piace che sia molto esplicito su da dove proviene tutto il codice, e non usa alcuna “magia”.

Supponendo che la root del progetto sia la directory di lavoro corrente, dovrebbe funzionare:

 // require built-in path module path = require('path'); // require file relative to current working directory config = require( path.resolve('.','config.js') ); 

Ecco il modo effettivo che sto facendo da oltre 6 mesi. Io uso una cartella denominata node_modules come mia cartella radice nel progetto, in questo modo cercherà sempre quella cartella da ovunque io chiamo un assoluto richiedono:

  • node_modules
    • il mio progetto
      • index.js Posso richiedere (“myProject / someFolder / hey.js”) invece di richiedere (“./ someFolder / hey.js”)
      • someFolder che contiene hey.js

Questo è più utile quando si è nidificati in cartelle ed è molto meno lavoro modificare un percorso se è impostato in modo assoluto. Io uso solo 2 la relativa richiesta nella mia intera app .

Potresti definire qualcosa di simile nel tuo app.js:

 requireFromRoot = (function(root) { return function(resource) { return require(root+"/"+resource); } })(__dirname); 

e poi ogni volta che vuoi richiedere qualcosa dalla radice, non importa dove ti trovi, basta usare requireFromRoot invece di richiedere la vaniglia. Funziona abbastanza bene per me finora.

Ho provato molte di queste soluzioni. Ho finito per aggiungere questo nella parte superiore del mio file principale (ad esempio index.js):

 process.env.NODE_PATH = __dirname; require('module').Module._initPaths(); 

Questo aggiunge la radice del progetto al NODE_PATH quando lo script viene caricato. Mi permette di richiedere qualsiasi file nel mio progetto facendo riferimento al relativo percorso dalla radice del progetto come var User = require('models/user') . Questa soluzione dovrebbe funzionare fintanto che si esegue uno script principale nella root del progetto prima di eseguire qualsiasi altra cosa nel progetto.

Imho il modo più semplice per raggiungere questo objective è creare un link simbolico all’avvio dell’app su node_modules/app (o come lo chiami tu) che punta a ../app . Quindi puoi semplicemente chiamare require("app/my/module") . I link simbolici sono disponibili su tutte le principali piattaforms.

Tuttavia, dovresti comunque suddividere le tue cose in moduli più piccoli e manutenibili che vengono installati tramite npm. Puoi anche installare i tuoi moduli privati ​​tramite git-url, quindi non c’è motivo di avere una directory app monolitica.

Nel tuo progetto puoi modificare qualsiasi file .js che viene utilizzato nella directory root e aggiungere il suo percorso a una proprietà della variabile process.env . Per esempio:

 // in index.js process.env.root = __dirname; 

Successivamente è ansible accedere alla proprietà ovunque:

 // in app.js express = require(process.env.root); 

Potresti usare un modulo che ho creato, Undot . Non è niente di avanzato, solo un aiutante in modo da poter evitare quei punti inferno con semplicità.

Esempio:

 var undot = require('undot'); var User = undot('models/user'); var config = undot('config'); var test = undot('test/api/user/auth'); 

Quello che mi piace fare è sfruttare il modo in cui il nodo carica dalla directory node_module per questo.

Se si tenta di caricare il modulo “cosa”, si farebbe qualcosa di simile

 require('thing'); 

Il nodo cercherà quindi la directory ‘cosa’ nella directory ‘node_module’.

Poiché node_module è normalmente alla radice del progetto, possiamo sfruttare questa coerenza. (Se node_module non è nella root, allora ci sono altri mal di testa autoindotti da affrontare).

Se entriamo nella directory e poi torniamo indietro, possiamo ottenere un percorso coerente alla radice del progetto del nodo.

 require('thing/../../'); 

Quindi se vogliamo accedere alla directory / happy, lo faremo.

 require('thing/../../happy'); 

Sebbene sia piuttosto un po ‘hacky, tuttavia, penso che se la funzionalità di come node_modules viene caricata, ci saranno problemi più grandi da affrontare. Questo comportamento dovrebbe rimanere coerente.

Per chiarire le cose, lo faccio perché il nome del modulo non ha importanza.

 require('root/../../happy'); 

L’ho usato di recente per angular2. Voglio caricare un servizio dalla radice.

 import {MyService} from 'root/../../app/services/http/my.service'; 

Alcune delle risposte stanno dicendo che il modo migliore è quello di aggiungere il codice al nodo_module come pacchetto, sono d’accordo e probabilmente è il modo migliore per perdere il ../../../ in require ma nessuno di loro in realtà dà un modo per farlo.

dalla versione 2.0.0 puoi installare un pacchetto da file locali, il che significa che puoi creare una cartella nella tua root con tutti i pacchetti che vuoi,

 -modules --foo --bar -app.js -package.json 

quindi in package.json puoi aggiungere i modules (o foo e bar ) come un pacchetto senza pubblicare o utilizzare un server esterno come questo:

 { "name": "baz", "dependencies": { "bar": "file: ./modules/bar", "foo": "file: ./modules/foo" } } 

Dopo di che fai npm install , e puoi accedere al codice con var foo = require("foo") , proprio come fai con tutti gli altri pacchetti.

maggiori informazioni possono essere trovate qui:

https://docs.npmjs.com/files/package.json#local-paths

e qui come creare un pacchetto:

https://docs.npmjs.com/getting-started/creating-node-modules

Non è ansible che la directory node_modules contenga node_modules con un collegamento simbolico alla radice del progetto project -> ../../ consentendo così agli esempi di utilizzare require('project') , sebbene ciò non rimuova la mapping, consente al source di usare require('project') piuttosto che require('../../') .

Ho provato questo, e funziona con v0.6.18.

Elenco della directory del project :

 $ ls -lR project project: drwxr-xr-x 3 user user 4096 2012-06-02 03:51 examples -rw-r--r-- 1 user user 49 2012-06-02 03:51 index.js project/examples: drwxr-xr-x 2 user user 4096 2012-06-02 03:50 node_modules -rw-r--r-- 1 user user 20 2012-06-02 03:51 test.js project/examples/node_modules: lrwxrwxrwx 1 user user 6 2012-06-02 03:50 project -> ../../ 

Il contenuto di index.js assegna un valore a una proprietà dell’object exports e richiama console.log con un messaggio che indica che era richiesto. Il contenuto di test.js è require('project') .

Se qualcuno sta cercando un altro modo per aggirare questo problema, ecco il mio contributo allo sforzo:

https://www.npmjs.com/package/use-import

L’idea di base: si crea un file JSON nella radice del progetto che mappa i percorsi dei file in nomi abbreviati (o si usi-automapper per farlo per te). Puoi quindi richiedere i tuoi file / moduli usando quei nomi. Così:

 var use = require('use-import'); var MyClass = use('MyClass'); 

Quindi c’è quello.

Ho scritto questo piccolo pacchetto che ti permette di richiedere pacchetti con il relativo percorso dalla radice del progetto, senza introdurre alcuna variabile globale o sovrascrivere i default del nodo

https://github.com/Gaafar/pkg-require

Funziona così

 // create an instance that will find the nearest parent dir containing package.json from your __dirname const pkgRequire = require('pkg-require')(__dirname); // require a file relative to the your package.json directory const foo = pkgRequire('foo/foo') // get the absolute path for a file const absolutePathToFoo = pkgRequire.resolve('foo/foo') // get the absolute path to your root directory const packageRootPath = pkgRequire.root() 

Un’altra risposta:

Immagina questa struttura di cartelle:

  • node_modules
    • lodash
  • src
    • subdir
      • foo.js
      • bar.js
    • main.js
  • test

    • test.js

Quindi in test.js , è necessario richiedere file come questo:

 const foo = require("../src/subdir/foo"); const bar = require("../src/subdir/bar"); const main = require("../src/main"); const _ = require("lodash"); 

e in main.js :

 const foo = require("./subdir/foo"); const bar = require("./subdir/bar"); const _ = require("lodash"); 

Ora puoi usare babel e il risolutore di moduli babel-plugin con questo. file babelrc per configurare 2 cartelle root:

 { "plugins": [ ["module-resolver", { "root": ["./src", "./src/subdir"] }] ] } 

Ora puoi richiedere i file nello stesso modo nei test e in src :

 const foo = require("foo"); const bar = require("bar"); const main = require("main"); const _ = require("lodash"); 

e se si desidera utilizzare la syntax del modulo es6 :

 { "plugins": [ ["module-resolver", { "root": ["./src", "./src/subdir"] }], "transform-es2015-modules-commonjs" ] } 

quindi importa i file in test e src in questo modo:

 import foo from "foo" import bar from "bar" import _ from "lodash" 

ho creato un modulo nodo chiamato “rekiure”

ti permette di richiedere senza l’uso di percorsi relativi

https://npmjs.org/package/rekuire

è super facile da usare

Stiamo per provare un nuovo modo per affrontare questo problema.

Prendendo esempi da altri progetti noti come spring e guice, definiremo un object “context” che conterrà tutte le istruzioni “require”.

Questo object verrà quindi passato a tutti gli altri moduli per l’uso.

Per esempio

 var context = {} context.module1 = require("./module1")( { "context" : context } ) context.module2 = require("./module2")( { "context" : context } ) 

Questo ci impone di scrivere ogni modulo come una funzione che riceve opts, che comunque ci considera come una best practice.

 module.exports = function(context){ ... } 

e poi farai riferimento al contesto invece di richiedere cose.

var module1Ref = context.moduel1;

Se lo si desidera, è ansible scrivere facilmente un ciclo per eseguire le istruzioni richieste

 var context = {}; var beans = {"module1" : "./module1","module2" : "./module2" }; for ( var i in beans ){ if ( beans.hasOwnProperty(i)){ context[i] = require(beans[i])(context); } }; 

Questo dovrebbe rendere la vita più facile quando vuoi prendere in giro (test) e anche risolvere il tuo problema lungo la strada mentre rendi il tuo codice riutilizzabile come un pacchetto.

È anche ansible riutilizzare il codice di inizializzazione del contesto separando la dichiarazione dei bean da esso. ad esempio, il tuo file main.js potrebbe sembrare così

 var beans = { ... }; // like before var context = require("context")(beans); // this example assumes context is a node_module since it is reused.. 

Questo metodo si applica anche alle librerie esterne, non è necessario codificare i loro nomi ogni volta che vengono richiesti, tuttavia richiede un trattamento speciale poiché le loro esportazioni non sono funzioni che prevedono il contesto.

In seguito possiamo anche definire i bean come funzioni – che ci permetteranno di require moduli diversi in base all’ambiente – ma che non rientrano nell’ambito di questo thread.

Ho avuto problemi con questo stesso problema, quindi ho scritto un pacchetto chiamato include .

Includi gli handle che individuano la cartella radice del tuo progetto individuando il tuo file package.json, quindi passa l’argomento path che dai alla richiesta nativa () senza tutto il relativo path path. Immagino che questo non sia una sostituzione di require (), ma uno strumento per richiedere la gestione di file o librerie non pacchettizzate / non di terze parti. Qualcosa di simile a

 var async = require('async'), foo = include('lib/path/to/foo') 

Spero che questo possa essere utile.

Se il file js del punto di ingresso della tua app (cioè quello su cui viene effettivamente eseguito il “nodo” attivo ) si trova nella directory root del progetto, puoi farlo facilmente con il modulo npm di rootpath . Basta installarlo tramite

 npm install --save rootpath 

…then at the very top of the entry point js file, add:

 require('rootpath')(); 

From that point forward all require calls are now relative to project root – eg require('../../../config/debugging/log'); becomes require('config/debugging/log'); (where the config folder is in the project root).

In simple lines, u can call your own folder as module :

For that we need: global and app-module-path module

here “App-module-path” is the module ,it enables you to add additional directories to the Node.js module search path And “global” is, anything that you attach to this object will b available everywhere in your app.

Now take a look at this snippet:

 global.appBasePath = __dirname; require('app-module-path').addPath(appBasePath); 

__dirname is current running directory of node.You can give your own path here to search the path for module.

Just want to follow up on the great answer from Paolo Moretti and Browserify. If you are using a transpiler (eg, babel, typescript) and you have separate folders for source and transpiled code like src/ and dist/ , you could use a variation of the solutions as

node_modules

With the following directory structure:

 app node_modules ... // normal npm dependencies for app src node_modules app ... // source code dist node_modules app ... // transpiled code 

you can then let babel etc to transpile src directory to dist directory.

symlink

Using symlink we can get rid some levels of nesting:

 app node_modules ... // normal npm dependencies for app src node_modules app // symlinks to '..' ... // source code dist node_modules app // symlinks to '..' ... // transpiled code 

A caveat with babel –copy-files The --copy-files flag of babel does not deal with symlinks well. It may keep navigating into the .. symlink and recusively seeing endless files. A workaround is to use the following directory structure:

 app node_modules app // symlink to '../src' ... // normal npm dependencies for app src ... // source code dist node_modules app // symlinks to '..' ... // transpiled code 

In this way, code under src will still have app resolved to src , whereas babel would not see symlinks anymore.

Just came across this article which mentions app-module-path . It allows you to configure a base like this:

 require('app-module-path').addPath(baseDir); 

Some time ago I created module for loading modules relative to pre-defined paths.

https://github.com/raaymax/irequire

You can use it instead of require.

 irequire.prefix('controllers',join.path(__dirname,'app/master')); var adminUsersCtrl = irequire("controllers:admin/users"); var net = irequire('net'); 

Maybe it will be usefull for someone..

Whilst these answers work they do not address the problem with npm test

If, for example, I create a global variable in server.js, it will not be set for my test suite execution.

To set a global appRoot variable that will avoid the ../../../ problem and will be available in both npm start AND npm test see:

Mocha tests with extra options or parameters

Note that this is the new official mocha solution .