-
Notifications
You must be signed in to change notification settings - Fork 64
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
Conditional required env? #78
Comments
Ooooh, I like that idea! That's not supported now, but I for one would love to see a PR for it 🙂 |
What about this? envalid.cleanEnv(process.env, {
USE_TLS: envalid.bool(),
TLS_CA_CERT_PATH: envalid.str({
requiredWhen: 'USE_TLS' // is true
}),
// ...
})
|
Great feature idea, I could see this being pretty useful. I worry that an approach like
|
Seems like it would probably be simpler to implement and answers both of my previous questions too, so that's a 👍 . |
Any news about this awesome feature? :) |
@antoine-pous check #81 PR |
@rainum that doesn't answer to my question, actually the feature is not merged and seem inactive from months. In a professional context i can't use a commit from a PR in progress :( |
Seems to be a nice feature. I think we need to send a new PR on it. |
This would be an awesome feature 👍 |
Something like the Something like this is possible already though using TypeScript and the json validator, if you can deal with having the related env vars stored together in json: import * as e from 'envalid'
// Read env vars from .env
require('dotenv').config()
type TlsJsonType = {
USE_TLS: false,
} | {
USE_TLS: true,
TLS_CA_CERT_PATH: string,
TLS_CERT_PATH: string,
TLS_KEY_PATH: string,
}
const env = e.cleanEnv(process.env, {
// TS type-checks that this default value works with the union type
TLS_CONFIG: e.json<TlsJsonType>({ default: { USE_TLS: false } }),
})
if (env.TLS_CONFIG.USE_TLS) {
// Within this guard clause, TS knows this is a string
console.log(env.TLS_CONFIG.TLS_KEY_PATH)
} Of course, the json() validator won't validate that particular shape at runtime, but you could create a custom validator that does that work there as well |
bumping this issue years later. Any progress? |
Any update on this? |
No updates, sorry– I think the approach in this comment is still doable: #78 (comment) I haven't had the time to add this but I'd welcome a PR 👍 |
const requiredIfEnabledSqlQListener = makeValidator((x) => {
const isEnabled = convertToBoolean(process.env. ENABLE_RAPTOR_SQL_LISTENER);
if (isEnabled && !x) {
throw new Error("required when ENABLE_RAPTOR_SQL_LISTENER is enabled");
}
return x;
});
const schema = {
ENABLE_RAPTOR_SQL_LISTENER: bool({ default: false }),
RAPTOR_SQL_DB: requiredIfEnabledSqlQListener(),
RAPTOR_SQL_IS_SSL: requiredIfEnabledSqlQListener(),
}; This is how I did it, remember to either put all the env variables in .env file to trigger the validation or set these as |
@gitSambhal I'm stuck on this. Does that code work? I can't manage to make it work here, I just need to have one optional env variable. I did it work like this, but it not look a good approach:
Can someone help me with a better solution? |
Hi @TiagoGouvea import { cleanEnv, str, port, bool, url, makeValidator } from 'envalid';
import dotenv from 'dotenv';
dotenv.config();
const myOptionalValidator = makeValidator((x) => {
const nodeEnv = process.env.NODE_ENV;
const isStagProd = ['production', 'staging'].includes(nodeEnv);
console.log('isStagProd', isStagProd);
if (!isStagProd) {
// don't validate here, just return the value
return x;
}
if(!x) {
throw new Error('The value is required')
}
return x;
});
const specs = {
DATABASE_URL: url(),
MY_OPTIONAL: myOptionalValidator(),
};
export const env = cleanEnv(process.env, specs); |
Is there a way to conditionally mark ENV vars as required based on the values of other ENV vars?
In my case, I have the following 4 vars:
USE_TLS
TLS_CA_CERT_PATH
TLS_CERT_PATH
TLS_KEY_PATH
If
USE_TLS
is true, then I want the other three flagged as required. If it is false, then the other three should be optional.The text was updated successfully, but these errors were encountered: