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

Comparing version 1.0.1 to 1.0.2

package.json

		{
		"name": "@thinkmill/devops-env-vars",
		"version": "1.0.1",
		"version": "1.0.2",
		"description": "Helper functions that encapsulate our treatment of environment vars for KeystoneJS apps",
		"main": "index.js",
		"scripts": {
		"release-patch": "npm version patch && git push && git push --tags",
		"test": "echo \"Error: no test specified\" && exit 1"
		@@ -8,0 +9,0 @@ },

README.md

		@@ -70,2 +70,5 @@ Devops: Environment Variables
		// ..

		// Lock and export the config vars
		module.exports = Object.freeze(config);
		```
		@@ -97,2 +100,15 @@

		Note this differs significantly from `NODE_ENV`, the only recognised value if which is `production`.
		The conventional relationship between `NODE_ENV` and `APP_ENV` is shown in the table below.

		\| Environment \| `APP_ENV` \| `NODE_ENV` \|
		\| ----------- \| --------- \| ---------- \|
		\| live \| 'live' \| 'production' \|
		\| staging \| 'staging' \| 'production' \|
		\| testing \| 'testing' \| (`undefined` or any value != 'production') \|
		\| development \| 'development' \| (`undefined` or any value != 'production') \|

		This may not hold for all apps, especially older apps created before our `APP_ENV` usage was codified.


		### `envLib.buildAppFlags(APP_ENV)`
		@@ -110,3 +126,3 @@

		```javascript
		```javascript
		console.log(flags);
		@@ -126,3 +142,3 @@ // { IN_LIVE: false, IN_STAGING: true, IN_TESTING: false, IN_DEVELOPMENT: false }
		This file should contain any credentials, settings, etc. that are required for the environment but too sensitive to store in the codebase.
		Mandrill API keys, merchant account credentials, production Mongo connection URIs, etc. might be required for a live system but generally aren't needed in development.
		Mandrill API keys, merchant account credentials, live Mongo connection URIs, etc. might be required for a live system but generally aren't needed in development.
		As such, the code above skips this step when `IN_DEVELOPMENT` is true.
		@@ -158,3 +174,3 @@

		As noted above, the `mergeConfig()` function doesn't modify the `process.env` scope.
		As noted above, the `mergeConfig()` function does not modify the `process.env` scope.
		Variables that are defaulted based on the validation rules supplied will only exist in the object returned by `mergeConfig()`.
		@@ -192,2 +208,3 @@
		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`:
		@@ -197,6 +214,6 @@
		config.CORE_API_URL = ({
		production: 'https://core.blueshyft.com.au',
		staging: 'https://core-staging.blueshyft.com.au',
		testing: 'https://core-testing.blueshyft.com.au',
		development: 'http://localhost:3000',
		live: 'https://core.blueshyft.com.au',
		staging: 'https://core-staging.blueshyft.com.au',
		testing: 'https://core-testing.blueshyft.com.au',
		development: 'http://localhost:3000',
		})[APP_ENV];
		@@ -218,3 +235,13 @@ ```
		// Can sweeps be 'reset' after email generation has started
		config.ALLOW_RESET_AFTER_EMAIL_GENERATION = !IN_PRODUCTION;
		config.ALLOW_RESET_AFTER_EMAIL_GENERATION = !IN_LIVE;
		```

		### 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.
		This prevents any other part of the application from accidenally making changes to this object.

		```javascript
		// Lock and export the config vars
		module.exports = Object.freeze(config);
		```

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

Improved metrics