V1 Migration Guide
This guide is intended to help with migration to v1.
Breaking Changes
Cfgu
format changes
V1 introduces several breaking changes to .cfgu
files. Below is a list of the breaking changes and how to update your .cfgu
files.
Cfgu
property changes
- The
type
property has been removed and replaced with the newtest
property. View migration examples below. - The
options
property has been renamed toenum
to better reflect its purpose. - The
depends
property has been removed. If you need to replicate it, you can use the newtest
property. - The
labels
property has been renamed tolabel
. - The
template
property has been removed. If you need to replicate it, you can use the newconst
property. View migration examples below.
.cfgu
file structure change
The file structure of .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:
After migration:
CLI changes
upsert command config assignment flag changes
The --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:
Will:
- Delete the value of
GREETING
. - Set the value of
SUBJECT
toconfigu
.
These changes aim to improve clarity and prevent naming conflicts while providing flexibility for key-value management.
Upsert command import flag removal
The --import
flag has been removed from the CLI upsert command.
Export command filtering flags changes
The following flags have been removed in favor of the new --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
Export command template input flag removal
The --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 changes
The cache
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.
Introduction of type coercion
V1 introduces type coercion to Configu. During evaluation, Configu will attempt to coerce values from ConfigStores to their expected type. This feature is intended to make Configu more flexible and easier to use.
Type coercion affects:
- All instances of config values in
ConfigExpressions
are coerced to the expected type (string
,number
,boolean
,object
,array
). You can access the value as it’s stored viastoredValue
. - The Configu CLI Eval command returns the coerced value in the output.
- The Configu CLI Export command receives the coerced value as input from Eval command which affects:
- The
--format
flag which will now receive the coerced value as input and appropriately formats it. - All instances of
ConfigExpressions
usages by--filter
,--template
,--map
,--reduce
,--sort
flags which will now receive the coerced value as input.
- The
- The Configu Proxy export route which will now coerce values to the expected type.
Upgrading Configu CLI
To use the latest Configu CLI, you can use the following command:
Upgrading Configu Proxy
Install the latest configu/proxy
docker image.
New Features
V1 introduces several new features to Configu. Below is a list of the new features and how to use them.
ConfigExpressions
V1 introduces a new feature called 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:
- lodash for various utility functions. Use
_
within theConfigExpression
to access lodash functions. - validator.js for string validations. Use
validator
within theConfigExpression
to access validator.js functions. - The JSONSchema utility class for JSON schema validations. Use
JSONSchema
orjsonschema
within theConfigExpression
to access the utility class. - Zod for schema validations with static type inference. Use
z
within theConfigExpression
to access Zod functions. - Chai for assertions functions. Use
assert
,expect
, andshould
respectively within theConfigExpression
to access Chai functions.
The following features support ConfigExpressions
:
- The new
test
Cfgu
property - The new
const
Cfgu
property - The
.configu
file - The CLI export
filter
flag - The CLI export
template
flag
Example usages of ConfigExpressions
:
test
Cfgu
property:
The CLI export filter
flag:
The CLI export template
flag, example template .env
file:
New Cfgu
property test
The 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:
Boolean type validation via validator.js
Example of using test
in place of depends
:
New Cfgu
property const
The 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
:
Default ConfigStore
You can now designate a 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:
CLI global --config
flag
The --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.
CLI .configu
auto-detection
The CLI now automatically recursively searches for .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.
CLI eval command defaults flag
The new --defaults
flag can now be used to evaluate default value from a ConfigSchema and skip querying a ConfigStore.
Other changes
@configu/node
and @configu/browser
removal
Any and all uses of these packages are no longer supported. We encourage all users of these packages to utilize @configu/cli
or @configu/proxy
depending on your requirements. All ConfigStore implementations have been moved to @configu/integrations
.
@configu/lib
removal
Superseded by @configu/common
which is a package that provides shared functionality for the higher-level interfaces.
@configu/ts
removal
Superseded by @configu/sdk
.
Introduction of @configu/integrations
A new package that contains all ConfigStore implementations and libraries that extend the 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.
Was this page helpful?