Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor!: environment variables validation #224

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

AlexanderLukin
Copy link
Contributor

Refactor environment variable validation rules. Apply consistent patterns to env validation.

The main motivation for this change was as follows:

  1. Make env validation more strict and consistent. Stick to the same validation patterns in different projects.

  2. Provide consistent fallback options for optional variables.

Here are the main changes:

  1. Previously if a user set an empty string as the variable name in the .env file like this: VARIABLE_NAME= not all variable initializers assigned a correct default value to the variable in this case. Now it is fixed. For the purpose of this improvement, now all optional variable initializers always have the @Transform decorator that provides a default value for the variable. Add the two special functions (toNumber and toBoolean) that support this change.

  2. Make validation of boolean variables more strict.
    CAUTION: This might be a breaking change for users who use values like "yes" to initialize boolean variables.

  3. Now the ETH_NETWORK variable is validated not only when the validator source is "Lido". Make validation of this variable more strict.
    CAUTION: Currently the EVM doesn't officially support testnets other than those listed in the Network interface. But this might be a breaking change if some users use EVM for other testnets.

  4. Implement the new toArrayOfUrls() function to provide a reasonable default value for variables that should have a list of URLs in their values. This function also fixes a bug with default values for such variables. Previously, if a user set an empty string as a value of such variables, the validation worked incorrectly.

  5. Now we validate that values in EL_RPC_URLS, CL_API_URLS, and VALIDATOR_REGISTRY_KEYSAPI_SOURCE_URLS are indeed URLs.

  6. The validation engine now removes trailing slashes from URL values.

  7. More consistent validation for the HTTP_PORT and DB_PORT values.

  8. Add @Optional decorator to all optional variables.

  9. Change @IsNumber to @IsInt.

  10. Move enums from the env.validation.ts to environment.interface.ts.

Refactor environment variable validation rules. Apply consistent
patterns to env validation.

The main motivation for this change was as follows:

1. Make env validation more strict and consistent. Stick to the same
validation patterns in different projects.

2. Provide consistent fallback options for optional variables.

Here are the main changes:

1. Previously if a user set an empty string as the variable name in the
.env file like this: ``` VARIABLE_NAME= ``` not all variable
initializers assigned a correct default value to the variable in this
case. Now it is fixed. For the purpose of this improvement, now all
optional variable initializers always have the `@Transform` decorator
that provides a default value for the variable. Add the two special
functions (`toNumber` and `toBoolean`) that support this change.

2. Make validation of boolean variables more strict. CAUTION: This might
be a breaking change for users who use values like "yes" to initialize
boolean variables.

3. Now the `ETH_NETWORK` variable is validated not only when the
validator source is "Lido". Make validation of this variable more
strict. CAUTION: Currently the EVM doesn't officially support testnets
other than those listed in the `Network` interface. But this might be a
breaking change if some users use EVM for other testnets.

4. Implement the new `toArrayOfUrls()` function to provide a reasonable
default value for variables that should have a list of URLs in their
values. This function also fixes a bug with default values for such
variables. Previously, if a user set an empty string as a value of such
variables, the validation worked incorrectly.

5. Now we validate that values in `EL_RPC_URLS`, `CL_API_URLS`, and
`VALIDATOR_REGISTRY_KEYSAPI_SOURCE_URLS` are indeed URLs.

6. The validation engine now removes trailing slashes from URL values.

7. More consistent validation for the `HTTP_PORT` and `DB_PORT` values.

8. Add `@Optional` decorator to all optional variables.

9. Change `@IsNumber` to `@IsInt`.

10. Move enums from the `env.validation.ts` to
`environment.interface.ts`.
Update validation rules for some variables. The main changes are:

1. Loosen validation rules for boolean variables. Now numbers "1" and
"0" and constants "yes" and "no" are accepted as valid boolean values.

2. Rename the `Network` interface to `Chain`.
@AlexanderLukin
Copy link
Contributor Author

Update validation rules for some variables. The main changes are:

  1. Loosen validation rules for boolean variables. Now numbers "1" and "0" and constants "yes" and "no" are accepted as valid boolean values.

  2. Rename the Network interface to Chain.

AlexanderLukin added a commit to lidofinance/lido-nestjs-modules that referenced this pull request Mar 19, 2024
In many application repositories, we have an environmental variable
validation engine. It is typical for this engine to have code that needs
to transform incoming environmental variable values to values of a
specific type. These tasks are repeatable in many projects:
lidofinance/ethereum-validators-monitoring#224
lidofinance/node-operators-widget-backend-ts#41
lidofinance/lido-keys-api#216

It makes sense to move this repeated code from many projects to some
common place.

The new "transform" module introduced in this PR collects these common
transformation functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant