This guide is intended to help with migration to v1.
Cfgu
format changes.cfgu
files. Below is a list of the breaking changes and how to update your .cfgu
files.
Cfgu
property changestype
property has been removed and replaced with the new test
property. View migration examples below.options
property has been renamed to enum
to better reflect its purpose.depends
property has been removed. If you need to replicate it, you can use the new test
property.labels
property has been renamed to label
.template
property has been removed. If you need to replicate it, you can use the new const
property. View migration examples below..cfgu
file structure change.cfgu
files has significantly changed to provide a more robust structure.
To update a .cfgu
file to the new structure, the Cfgu
declarations need to be moved under the keys
property.
We will provide an example of how to migrate this example .cfgu
file:
--config, -c
flag has been renamed to --kv
to avoid clashes with the new --config
global flag. Replace all occurrences of --config
with --kv
to align with this updated naming convention.
A new method for declaring key-value pairs has also been introduced using the -k
/--key
and -v
/--value
flags. These flags must be used in sequence, with each key matched to the corresponding value provided immediately after. Keys without matching values will result in the deletion of their corresponding values.
For example, the following command:
GREETING
.SUBJECT
to configu
.--import
flag has been removed from the CLI upsert command.
--filter
flag along with how they can be replaced with --filter
:
--pick-label
--omit-label
--pick-key
--omit-key
--pick-hidden
--omit-hidden
--pick-empty
--omit-empty
--template-input
flag has been removed. You can instead adjust the input as needed via the ConfigExpression
utilities and mutate the $.configs
(provided as an object) context input to whatever you need.
.configu
file changescache
property has been renamed to backup
to more accurately reflect its purpose. Replace all occurrences of cache
with backup
to reflect the new naming convention.
ConfigExpressions
are coerced to the expected type (string
, number
, boolean
, object
, array
). You can access the value as it’s stored via storedValue
.--format
flag which will now receive the coerced value as input and appropriately formats it.ConfigExpressions
usages by --filter
, --template
, --map
, --reduce
, --sort
flags which will now receive the coerced value as input.configu/proxy
docker image.
ConfigExpressions
ConfigExpressions
. ConfigExpressions
allow you to write dynamic values with certain features like string interpolation, arithmetic operations, and more. All features that support ConfigExpressions
have their own injected context that can withing the ConfigExpressions
for evaluation.
The ConfigExpressions
contexts include the following libraries:
_
within the ConfigExpression
to access lodash functions.validator
within the ConfigExpression
to access validator.js functions.JSONSchema
or jsonschema
within the ConfigExpression
to access the utility class.z
within the ConfigExpression
to access Zod functions.assert
, expect
, and should
respectively within the ConfigExpression
to access Chai functions.ConfigExpressions
:
test
Cfgu
propertyconst
Cfgu
property.configu
filefilter
flagtemplate
flagConfigExpressions
:
test
Cfgu
property:
filter
flag:
template
flag, example template .env
file:
Cfgu
property test
test
property is a new property that allows you to write ConfigExpressions
to validate the value of a key. It replaces the type
property which was removed due to its limited functionality.
Here are a few examples of how test
can be used in place of type
String type validation via Chai assertion:
test
in place of depends
:
Cfgu
property const
const
property is a new property that allows you to write ConfigExpressions
to set a constant value for a key.
Example usage of const
instead of template
:
ConfigStore
ConfigStore
as the default by adding the default
property to its configuration and setting it to true
. This default will be used whenever a ConfigStore
is omitted as an input in actions performed using Configu’s high-level interfaces.
If your .configu
file contains only a single ConfigStore
, it will be automatically detected and treated as the default.
Example definition of a default ConfigStore
in a .configu
file:
--config
flag--config
flag is a new global flag that allows you to specify a path to .configu
file to use for all commands. This flag is useful when you want to use a specific .configu
file that you want to use for all commands.
.configu
auto-detection.configu
files from the current working directory upwards to the home directory and uses the first one found for all commands when the --config
flag is not provided.
--defaults
flag can now be used to evaluate default value from a ConfigSchema and skip querying a ConfigStore.
@configu/node
and @configu/browser
removal@configu/cli
or @configu/proxy
depending on your requirements. All ConfigStore implementations have been moved to @configu/integrations
.
@configu/lib
removal@configu/common
which is a package that provides shared functionality for the higher-level interfaces.
@configu/ts
removal@configu/sdk
.
@configu/integrations
ConfigExpressions
functionality which are decoupled from the core @configu/sdk
package. This package is intended to be used by higher-level configu interfaces such as the CLI and proxy.