You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although I like this feat, I vote for it to be an optional feature because sometimes we may need to have multiple variables just for rapid testing purposes as the env file will be still valid (I'm thinking of dotenv here)
Although I like this feat, I vote for it to be an optional feature because sometimes we may need to have multiple variables just for rapid testing purposes as the env file will be still valid (I'm thinking of dotenv here)
Maybe under the flag --no-duplicate, idk
Interesting, can you explain why you would have multiple values for a variable? Doesn't a line comment (#) cover this use case? 🤔
it does but (for me, while I'm testing various values) duplicating the line + changing it is quickler than duplicating + comment-in + changing the other one
But yeah, at same time I might not need to use envful before removing those duplicated values
My real concern here is that: before, I was using envful to check the presence of env. vars, but now (after that feat) it's also doing some validation that could be too strict (as dotenv won't complain on duplicate values)
This feature proposes adding a warning/error on the case that a user's environment defines two variables with the same name. For example:
This could catch situations in a user runs runs a process with an unintended env.
The text was updated successfully, but these errors were encountered: