7.3.0 breaking change? about envalid HOT 11 CLOSED

I can't seem to reproduce this with my minimal test case (below). What is the value of ITierEnum in your case? I'm guessing it's a string enum?

const env = envalid.cleanEnv(process.env, {
  POLICIES: envalid.json({
    default: JSON.stringify({
      bP: {
        free: { users: 1, monthly: 0, annually: 0 },
        basic: { users: 1, monthly: 0, annually: 0 },
      }
    })
  }),
})

from envalid.

My configuration works in 7.2 but not anymore in 7.3.

/** The tier of the Organization */
export declare const enum ITierEnum {
    free = "free",
    basic = "basic",
    premium = "premium",
    enterprise = "enterprise"
}

from envalid.

Hmm, the following test case still works for me using the enums:

const enum ITierEnum {
    free = "free",
    basic = "basic",
    premium = "premium",
    enterprise = "enterprise"
}

const env = envalid.cleanEnv(process.env, {
  POLICIES: envalid.json({
    default: JSON.stringify({
      bP: {
        [ITierEnum.free]: { users: 1, monthly: 0, annually: 0 },
        [ITierEnum.basic]: { users: 1, monthly: 0, annually: 0 },
      }
    })
  }),

Could you share some more of the traceback of that error? Are you using any custom middlewares?

from envalid.

I just updated envalid to version 7.3.0 and noticed some environment variables relying on default values breaking with the update. I think it's related to this change: ef5a895

Previously, a default value for a custom validator doing eg. JSON parsing would be ran through that validator, causing issues if you tried to define the default value as an object (but satisfying TypeScript typings for the validator). Instead, we had to define the default values as strings, so that they could be properly parsed by the validator.

from envalid.

@Pinqvin could you post a minimal repro case here?

from envalid.

https://github.com/Pinqvin/envalid-repro With [email protected] the values you get for TEST and TEST_CUSTOM are objects, but when you upgrade to 7.3.0, you get string values out. This is what lead to unexpected runtime behaviour, when I upgraded to 7.3.0

from envalid.

Thank you @Pinqvin for that, I think you are correct and this is unfortunately a breaking change that I should have highlighted:

default values are not passed through validation logic, they are default *output* values.

So if you have default values for json variables, the default value should be want you want to appear in the output, not an unparsed string value. There is more context on #176. Sorry for the inconvenience here, hope you're able to migrate your default values over without issues

from envalid.

@af Is that an intended change? When we pass a JSON stringify to env, we expect it to be an Object value instead of a string. Is that an intended change in v7.3? I think this is a bug to be addressed. This has been a big setback for using JSON type.

from envalid.

The change should only apply to provided default values, the actual strings passed in through the env vars should still be converted from string -> object via JSON.parse as before. If that is not happening for you somehow please let me know

from envalid.

@af Is not the output of the config is string not object? It doesn't relate to the input default value or not.

from envalid.

@veeramarni the output of the config should be the same as before, if the value is being provided from an actual env var. For example:

given this foo.ts:

const env = envalid.cleanEnv(process.env, {
  K: envalid.json(),
})
console.log(typeof env.K, env.K)

Running K='{"foo": 234}' ts-node foo.ts prints object { foo: 234 } as expected for me. If you have a repro case where it doesn't work like that please share it.

Regarding the initial issue you posted here, if you remove the JSON.stringify() in your default value I would think your example should work as expected on 7.3.0?

from envalid.