defaulted - npm Package Compare versions
Comparing version 1.0.1 to 1.0.2
| { | ||
| "name": "defaulted", | ||
| "version": "1.0.1", | ||
| "description": "Build config from environment variables and sensible defaults, with typing and validation.", | ||
| "version": "1.0.2", | ||
| "description": "Manage config from environment variables with sensible defaults, with typing and validation.", | ||
| "author": "Alec Perkins <mail@alecperkins.me>", | ||
@@ -14,3 +14,3 @@ "license": "MIT", | ||
| }, | ||
| "homepage": "https://alecperkins.net/defaulted", | ||
| "homepage": "https://alecperkins.net/tools/defaulted/", | ||
| "keywords": [ | ||
@@ -36,4 +36,3 @@ "config", | ||
| "./package.json": "./package.json" | ||
| }, | ||
| "peerDependencies": {} | ||
| } | ||
| } |
@@ -62,3 +62,3 @@ | ||
| Trying to access or set values not defined will throw: | ||
| Trying to access config keys not defined or set any will throw: | ||
@@ -94,3 +94,3 @@ ```javascript | ||
| If you _do_ want to send email from your local machine, you can disable the mocking just for that "deployment" by starting the server with something like `MOCK_EMAIL=false npm start`. Conversely, a deployment with `ENVIRONMENT=prod` will not mock email by default unless the overridden by the environment. The `prod` environment also requires the `DATABASE_URL` be defined, while local dev doesn't need any additional configuration out of the box. | ||
| If you _do_ want to send email from your local machine, you can disable the mocking just for that "deployment" by starting the server with something like `MOCK_EMAIL=false npm start`. Conversely, a deployment with `ENVIRONMENT=prod` will not mock email by default unless overridden by the environment. The `prod` environment also requires the `DATABASE_URL` be defined, while local dev doesn't need any additional configuration out of the box. | ||
@@ -142,3 +142,3 @@ | ||
| Like regular `defaulted`-based configs, accessing keys not specified in the initial list, trying to set a key, or trying to override an unspecified key will throw. These operations will also fail type checking but require the list of keys being marked `as const` for thorough strictness. | ||
| Like regular `defaulted`-based configs, accessing keys not specified in the initial list, trying to set a key, or trying to override an unspecified key will throw. These operations will also fail type checking but make sure the list of keys is marked `as const` for thorough strictness. | ||
@@ -203,2 +203,16 @@ ```typescript | ||
| With this setup, it’s easy to trace the usage of any particular config, and especially the secrets: | ||
| ```javascript | ||
| import config, { secrets } from "./config"; | ||
| import APIClient from "some-api"; | ||
| export function getAPIClient () { | ||
| return new APIClient(config.SOME_API_URL, { | ||
| token: secrets.SOME_API_KEY, | ||
| }); | ||
| } | ||
| ``` | ||
| #### ENVIRONMENT names | ||
@@ -209,3 +223,3 @@ | ||
| - `"dev"` is any non-production deployment, be it Staging, QA, UAT, SIT, or any other name or acronym, potentially even locally on a developer machine (there could be any number of deployments or stages in a pipeline using this `ENVIRONMENT`) | ||
| - `"test"` is any CI or similar test context that has needs specific changes for automation or instrumentation | ||
| - `"test"` is any CI or similar test context that needs specific changes for mocking or instrumentation | ||
| - `"local"` is a good alternative to `"dev"` when perhaps certain infrastructure pieces like queues need to be simulated | ||
@@ -215,3 +229,5 @@ | ||
| Note that different deployments can share an `ENVIRONMENT` but set different values in their specific instance. The `EVIRONMENT` is just a label that selects a set of config defaults and expectations as defined in the code. | ||
| #### 12 Factor Config | ||
@@ -221,5 +237,7 @@ | ||
| It does, and it’s right! `defaulted` is more precisely a way to manage the _defaults_, and ensure consistency. It seeks a balance between the purity of env-based config with the practicality of consistent groupings with centralized declarative defaults. In practice there usually are at least two classes of config. External tools can help manage this, but apps should own their expectations of configuration while allowing for explicit overrides on a per-deployment basis. | ||
| It does, and it’s right! `defaulted` is more precisely a way to manage the _defaults_, and ensure consistency. It seeks a balance between the purity of env-based config with the practicality of consistent groupings with centralized declarative defaults. | ||
| In practice, unless you’re always doing it live there usually are at least two classes of config: production and non-production. External tools can help manage this, but apps should own their expectations of configuration while allowing for explicit overrides on a per-deployment basis. | ||
| #### Why not NODE_ENV? | ||
@@ -226,0 +244,0 @@ |
Sorry, the diff of this file is not supported yet
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
No website
QualityPackage does not have a website.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
No website
QualityPackage does not have a website.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by2.28%
25526
- Number of lines in readme file
- increased by7.29%
265
Worsened metrics
- Lines of code
- decreased by-0.32%
313
No dependency changes