2012-06-25 9 views

risposta

0

Un modo davvero disordinato per raggiungere questo obiettivo nota

https://github.com/possibilities/meteor-environment-hooks

: l'interfaccia è IMHO OK, l'implementazione è disordinata

+0

Questo è adatto solo per le situazioni più elementari e non funzionerà se si desidera testare il proprio env sul computer locale senza eseguire una distribuzione completa. –

+0

Sì, sicuramente uno stop gap. Funziona comunque nelle situazioni di base. Lo uso per impostare l'id api in modo appropriato per il nuovo sistema di autenticazione, ma sono desideroso di sostituirlo con una soluzione migliore. –

1

C'è un open pull request a github che consentirebbe per questo. Commenta/Vota per questo, quindi è più probabile che venga incluso!

18

È possibile utilizzare Meteor.settings accoppiato con l'opzione --settings utilizzato durante l'esecuzione meteor run o meteor deploy.

Ad esempio, per l'esecuzione in modalità dev, creare un file JSON, chiamarlo meteorConfigDev.json, e inserire il seguente in esso:

{ 
    "public" : { 
    "mode" : "dev" 
    }, 
    "anotherProperty" : "anotherValue" 
} 

Eseguire la vostra applicazione utilizzando

meteor --settings meteorConfigDev.json 

On il server e sul client è possibile accedere alla "modalità" utilizzando:

Meteor.settings.public.mode //in this case it will be "dev" 

Nota che set sono disponibili "public" sia sul server che sul client, mentre tutto il resto (in questo caso "anotherProperty") è disponibile solo sul server.

È quindi possibile avere diversi file di configurazione per i diversi ambienti.

30

Sul server:

var inDevelopment = function() { 
    return process.env.NODE_ENV === "development"; 
}; 

var inProduction = function() { 
    return process.env.NODE_ENV === "production"; 
}; 

Meteor imposta la variabile d'ambiente NODE_ENV allo "sviluppo" quando si esegue meteor. In produzione, puoi impostare la variabile su qualsiasi cosa desideri, altrimenti verrà automaticamente impostata su "produzione".

Aggiornamento: Ho creato un pacchetto intelligente per consentire che questo funzioni sul client e sul server.

mrt add allow-env 

Basta impostare le regole di autorizzazione in un file server.

allowEnv({ 
NODE_ENV: 1 
}); 
+1

Questo non funziona per me, dato che la mia app è auto-ospitata e quando lancio la mia app tramite "meteor run --production" meteora ancora process.env.NODE_ENV a "sviluppo" (non sembra ragionevole, ma hanno il loro resons - vedi link). Questo è un problema noto per anni e ad es. discusso qui: https://github.com/meteor/meteor/issues/1858. – DerWOK

+0

"altrimenti sarà impostato su" produzione ": non dipende da dove ospiti/quali strumenti usi per l'hosting? –

4

Molto facile. Sto facendo funzionare la mia app su cinque (sì, cinque!) Ambienti diversi. Uso semplicemente un'istruzione switch su ROOT_URL come mostrato di seguito per quattro ambienti diversi. Certo, puoi usare un if-else se hai solo due ambienti. Funziona sul server. Basta creare un nuovo file chiamato startup.js e utilizzare l'esempio di codice seguente. Saluti!

switch (process.env.ROOT_URL) { 
    case "http://www.production.com/": 
     BLOCK OF CODE HERE 
     break; 
    case "http://www.staging.com/": 
     BLOCK OF CODE HERE 
     break; 
    case "http://www.development.com/": 
     BLOCK OF CODE HERE 
     break; 
    case "http://localhost:3000/": 
     BLOCK OF CODE HERE 
     break; 
} 

In generale, il formato per un'istruzione switch in JavaScript è

switch(expression) { 
    case n: 
     code block 
     break; 
    case n: 
     code block 
     break; 
    default: 
     default code block 
} 

UPDATE: Nota che Meteor offre ora Meteor.absoluteUrl(), che è simile a process.env.ROOT_URL con l'aggiunta di funzionalità extra. Vedi docs.

+0

Ho visto diverse app infrangere a causa di codice simile Questo codice rende la tua funzionalità dipendente da un proprietà che è indipendente dall'ambiente (l'URL) .Se l'URL viene modificato, la funzionalità può interrompersi e potenzialmente nessuno se ne accorge. Inoltre, devi modificare un punto in più nel codice ora se desideri cambiare l'URL (o aggiungerne un altro uno), che potresti aver dimenticato in pochi mesi: le funzionalità che dipendono dall'ambiente sono spesso vitali per la tua app, non facili da testare in modo pulito e non così ben curate, quindi devi fare molta attenzione. – opyh

+0

@opyh : "Come fa X sapere se gira su Y?" È una domanda che mette in discussione l'ambiente. Come sei disposto a rispondere a questa domanda senza ispezionare l'ambiente nt? Tali risposte sarebbero fuori dal campo di applicazione. Questo non ha mai rotto nella mia esperienza; quindi, sembra che tu debba trovare alcuni esempi e una soluzione migliore se sei così convinto che questo è sbagliato. –

+2

Non ho sconsigliato di controllare il tuo 'env', ma che non dovresti dedurre il tuo ambiente da un URL, perché l'URL può cambiare indipendentemente dal tuo ambiente per vari motivi. Se il tuo collega non sa che il tuo ROOT_URL ha un extra-significato "magico" per la tua logica di app, ci sono 3 casi realistici che potrebbero interrompere la tua app in produzione: 1) rimuovi 'www.', 2) cambia 'http' a' https', 3) hanno più URL che appartengono all'app di produzione e modificano l'URL predefinito. Inoltre è contro il principio [DRY] (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). – opyh

47

Dal Meteor 1.3 queste bandiere lavorare fuori dalla scatola:

Meteor.isDevelopment 
Meteor.isProduction 
Meteor.isTest 
Meteor.isAppTest 
+2

Questa deve essere la risposta accettata. –

Problemi correlati