@thinkmill/devops-env-vars - npm Package Compare versions

Comparing version 1.0.2 to 1.0.3

index.js

@@ -18,4 +18,4 @@ 'use strict';
 	'10.130.0.0/16': 'live',
+	'10.131.0.0/16': 'staging',
 	'10.132.0.0/16': 'testing',
-	'10.131.0.0/16': 'staging',
 };
@@ -22,0 +22,0 @@

package.json

 {
   "name": "@thinkmill/devops-env-vars",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "description": "Helper functions that encapsulate our treatment of environment vars for KeystoneJS apps",
@@ -5,0 +5,0 @@ "main": "index.js",

README.md

@@ -14,2 +14,6 @@ Devops: Environment Variables
 
+// This doesn't actually stop the config from being loaded onto clients, it's just a warning for developers
+if (typeof window !== 'undefined') throw new Error(`You definitely shouldn't require ./config on the client`);
+
+
 const envLib = require('@thinkmill/devops-env-vars');
@@ -76,9 +80,20 @@ const path = require('path');
 
+Lets step though the code above in detail.
 
-## Breakdown
 
-Lets step though the code above in detail.
+## Client-side Inclusion
 
-### `envLib.determineAppEnv(process.env.APP_ENV)`
+Since some of the config variables are also often needed client side, there's a temptation to simply require `config.js` there too.
+This is a terrible, terrible idea; it usually exposes security-sensitive values to the end user.
+The `config.js` file should simply never leave the server.
+We put this warning in place as a last ditch effort to prevent accidental inclusion.
 
+```javascript
+// This doesn't actually stop the config from being loaded onto clients, it's just a warning for developers
+if (typeof window !== 'undefined') throw new Error(`You definitely shouldn't require ./config on the client`);
+```
+
+
+## `envLib.determineAppEnv(process.env.APP_ENV)`
+
 First, we call `determineAppEnv()`, which determines the current `APP_ENV` by inspecting the servers IP address the `APP_ENV` value supplied by `process.env` (if present):
@@ -114,3 +129,3 @@
 
-### `envLib.buildAppFlags(APP_ENV)`
+## `envLib.buildAppFlags(APP_ENV)`
 
@@ -132,3 +147,3 @@ Once we have the `APP_ENV` we can use this function to build out a set of flags representing the different environments:
 
-### `dotenv.config(..)`
+## `dotenv.config(..)`
 
@@ -153,3 +168,3 @@ Next, standard practice is to seek out a `.env` file in the directory above the application root, named for the current `APP_ENV`:
 
-### `envLib.mergeConfig(APP_ENV, flags, process.env, rules)`
+## `envLib.mergeConfig(APP_ENV, flags, process.env, rules)`
 
@@ -178,3 +193,3 @@ The values loaded are next verified and assembled into the `config` object:
 
-### Other Config Values
+## Other Config Values
 
@@ -187,3 +202,3 @@ Most apps will also use a number of values that don't need to be set externally (ie. by `process.env` or the `.env` file).
 
-#### Static Values
+### Static Values
 
@@ -207,19 +222,47 @@ Values that are constant for now but may change in future. Eg..
 
-#### Derived Values
+### Addressing External Systems
 
-Many important values can be determine from other existing `config` values.
-Values set in this way can't be overridden/set without code changes.
-Eg. the URLs of related systems from `APP_ENV`:
+Many (all?) Thinkmill apps rely on external systems that differ between environments (`APP_ENV`).
+This is especially true in for blueshyft, where requests often require the cooperation of shared 
+internal services (such as the core, transaction engine, etc) and external services (such as remote partner APIs).
 
+#### blueshyft Apps
+
+For the blueshyft network of apps, the 
+[`@thinkmill/blueshyft-network` package](https://www.npmjs.com/package/@thinkmill/blueshyft-network) 
+was developed to centralise the addressing of apps across environments.
+Usage of the package looks like this:
+
 ```javascript
-config.CORE_API_URL = ({
-	live:          'https://core.blueshyft.com.au',
-	staging:       'https://core-staging.blueshyft.com.au',
-	testing:       'https://core-testing.blueshyft.com.au',
-	development:   'http://localhost:3000',
+const network = require('@thinkmill/blueshyft-network');
+
+// Pull in any vars we want for the network config (for this APP_ENV) and merge them into our config
+config = Object.assign(config, network.getVars(APP_ENV, [
+	'CORE_API_URL',
+	'PCA_TRANSACTIONS_API_URL',
+	'TLS_ECOSYSTEM',
+]));
+```
+
+See the [package docs](https://www.npmjs.com/package/@thinkmill/blueshyft-network) for details.
+
+#### Non-blueshyft Apps
+
+In non-blueshyft systems, an implementation pattern has evolved to define a set of values while maintaining readability.
+
+```javascript
+config.PLUMBUS_API_URL = ({
+	live:          'https://api.plumbus.net.au',
+	staging:       'https://api-staging.plumbus.net.au',
+	testing:       'https://api-testing.plumbus.net.au',
+	development:   'http://localhost:7634',  // Plumbus stub server
 })[APP_ENV];
 ```
 
-#### Feature Flags
+Since both these approaches add values directly to the config object (without using `mergeConfig()`), 
+values set in this way can't be overridden/set without code changes.
 
+
+### Feature Flags
+
 It's often useful to control specific code branches with individual flags.
@@ -239,5 +282,6 @@ These examples taken from the `blueshyft-transactions-api` codebase:
 
-### Exporting the Values
+## Exporting the Values
 
-The final lines in our example export the `config` object we've created for use by the app after [freezing](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze) it.
+The final lines in our example export the `config` object we've created for use by the app after 
+[freezing](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze) it.
 This prevents any other part of the application from accidenally making changes to this object.
@@ -249,1 +293,2 @@
 ```
+

No alert changes

Improved metrics

Total package byte prevSize

19848

increased by11.11%

Number of lines in readme file

285

increased by18.75%

No dependency changes