Geek Answers Handbook

How to set process.env before running a browser script?

The initial html comes from the source code. The server has a specific process.env.NODE_ENV (as well as other environment variables). The code being reviewed is built and works in several environments ( staging , production , etc.). Therefore, it is impossible to include environment variables in a browser script (for example, through envify ). I would like to be able to write environment variables in the processed html and use these variables for the code browser. Is it possible?

This is how I imagine it being done:

 <html> <head> <script>window.process = {env: {NODE_ENV: 'production'}};</script> <script src="/build/browserified_app.js"></script> </head> </html>
+7
browserify
source share
5 answers

Instead of hardcoding variables here and there use the envify plugin.

 npm install envify

This plugin automatically changes process.env.VARIABLE_HERE to what you passed as an argument to envify.

For example:

 browserify index.js -t [ envify --DEBUG app:* --NODE_ENV production --FOO bar ] > bundle.js

In your application, process.env.DEBUG will be replaced by app:* , process.env.NODE_ENV will be replaced by production and so on. This is a clean && elegant way, in my opinion, to handle this.

+9
source share

You can modify the entry point file, which will basically do this setup, and then require the original main file.

 process.env.NODE_ENV = 'production'; require('app.js');

Another way (imo much cleaner) is to use a conversion like envify that directly replaces your NODE_ENV in the code with a string value.

Option 1

I think your approach should usually work, but I would write directly to process.env , as I am sure that it is being overwritten in the kit. Instead, you can make a global variable like __env , and then in the actual package code, set it to process.env in your input file. This is an untested solution, but I believe it should work.

Option 2

Use localStorage and let the main script read the variables from there on initialization. You can set the variables in localStorage manually, or you can even give them to the server if you have them. The developer will simply open the console and type something like loadEnv('production') , it will do XHR and save the result in localStorage. Even with a manual approach, there is still the advantage that they do not need to hardcode in html.

If the manual does not look good enough, and the server is also a dead end, you can simply include all the variables from all environments (if they exist somewhere) in the set, and then use the switch to select the correct ones under certain conditions (for example, localhost, host manufacturer).

When you think about it, you are certainly outside the scope of Browserify with your needs. He can make a package for you, but if you do not want to receive this information in a bundle, you are on your own.

+2
source share

So, I decided that the web server job inserts environment variables. In my script, different logs were required per environment (for example, "local", "test", "prod").

the code:

 var express = require('express') , replace = require('replace'); ... var app = express(); var fileToReplace = <your browserified js here>; replace({ regex: 'ENV_ENVIRONMENT' , replacement: process.env.ENVIRONMENT , paths: [fileToReplace] }); ... app.listen(process.env.PORT);

I hard coded "ENV_ENVIRONMENT", but you can create an object in your package. json and configure it.

This certainly works, and it makes sense because it is perhaps the only entry point to the server.

+1
source share

First I managed to write to the json file, and then import this json file anywhere I needed to read the environment.

So in my gulp file:

 import settings from './settings'; import fs from 'fs'; ... fs.writeFileSync('./settings.json', JSON.stringify(settings));

In the settings.js file:

 if(process.env.NODE_ENV) { console.log('Starting ' + process.env.NODE_ENV + ' environment...'); } else { console.log('No environment variable set.'); process.exit(); } export default (() => { let settings; switch(process.env.NODE_ENV) { case 'development': settings = { baseUrl: '...' }; break; case 'production': settings = { baseUrl: 'some other url...' }; break; } return settings; })();

Then you can import the settings.json file into any other file, and it will be static, but it will contain the current environment:

 import settings from './settings.json'; ... console.log(settings.baseUrl);

I came here to find a cleaner solution ... good luck!

+1
source share

I ran into this problem creating isomorphic responsive applications. I use the following (well, this is a bit hacky) solution:

I assign env to the window object, of course, I do not disclose all env vars, only those that can be shared (without secret password keys, etc.).

 // code... const expose = ["ROOT_PATH", "ENDPOINT"]; const exposeEnv = expose.reduce( (exposeEnv, key) => Object.assign(exposeEnv, { [key]: env[key] }), {} ); // code... res.send(`<DOCTYPE html> // html... <script>window.env = ${JSON.stringify(exposeEnv)}</script> // html... `); // code...

then in my applications the entry point for clients (oh, yes, you must have one entry point) I do this:

 process.env = window.env;

YMMV AKA WFM!

+1
source share

More articles:


All Articles