process.env.CUSTOM_FEATURE_ENABLED = 'true'; // environment variables are always a string - loaded by k8s for example
export default () => ({
"CUSTOM_FEATURE_ENABLED": process.env.CUSTOM_FEATURE_ENABLED === 'true'
})
Loading this into the ConfigModule and then reading the value using:
const value = configService.get('CUSTOM_FEATURE_ENABLED');`
leads to the value being string true instead of a boolean value, this happens because the ConfigService tries to load the value from the environment variables first (instead of preferring to load from the custom configuration)
The PR includes tests that confirm this (unexpected) behaviour.
Expected behavior
I expect the environment variables to be checked last, not first.
Let me know if you think otherwise.
Package version
3.2.3
NestJS version
No response
Node.js version
No response
In which operating systems have you tested?
[X] macOS
[X] Windows
[ ] Linux
Other
Not using the same name as the config property name and the environment variable name could solve this, cause there won't be a clash.
But still, I believe this is a major issue, we should let the developer choose whatever property name they want, without the knowledge of their runtime environment variables.
I imagine the PR for this will be fairly straight forward (just changing the order of read), so I can submit it once we agree that this needs attention.
Is there an existing issue for this?
Current behavior
Imagine the following custom configuration:
Loading this into the ConfigModule and then reading the value using:
leads to the
value
being stringtrue
instead of a boolean value, this happens because the ConfigService tries to load the value from the environment variables first (instead of preferring to load from the custom configuration)Minimum reproduction code
https://github.com/sorooshme/config/pull/1
Steps to reproduce
The PR includes tests that confirm this (unexpected) behaviour.
Expected behavior
I expect the environment variables to be checked last, not first.
Let me know if you think otherwise.
Package version
3.2.3
NestJS version
No response
Node.js version
No response
In which operating systems have you tested?
Other
Not using the same name as the config property name and the environment variable name could solve this, cause there won't be a clash.
But still, I believe this is a major issue, we should let the developer choose whatever property name they want, without the knowledge of their runtime environment variables.
I imagine the PR for this will be fairly straight forward (just changing the order of read), so I can submit it once we agree that this needs attention.