feat: add support for generics in built-in validators

[SimenB]

Especially nice combined with choices as it'll be a type error to include an illegal value there.

@lostfictions thoughts?

[lostfictions]

Hey, nice idea! Unfortunately I'm not sure it makes too much sense in practice. Take the test case you added for this PR:

const strictEnv = cleanEnv(
    process.env,
    {
        ONLY_HELLO: str<'hello'>({
            example: 'example',
            docs: 'http://example.com'
        })
    },
    { strict: true }
)

const myStringWhichCanOnlyBeHello: 'hello' = strictEnv.ONLY_HELLO

This will compile just fine, but there's nothing stopping you from doing this with the compiled file:
$ ONLY_HELLO=goodbye node validate.js

Envalid won't throw an error if you do! It's important to remember that TypeScript doesn't emit any runtime checks, and the validator doesn't specify the specific values the string can be -- only that it's a string. The upshot is that myStringWhichCanOnlyBeHello will be typed as having a literal value of "hello" but at runtime will have a value of "goodbye". Not ideal!

---

All that said, it might be possible to add better inference to Spec<T>, allowing it to infer the type parameters from possible values listed if its choices field is included. But I'm a bit wary that that might get complicated quick, or run into the same issue -- we don't want TypeScript to be able to make promises to the user that it can't keep. If you're interested in a more thorough typesafe runtime validation system, io-ts is pretty cool -- it's built from the ground up to be able to provide those kinds of guarantees in a composable way.

[af]

Echoing @lostfictions, I'm not sure this gains us very much given there's no additional runtime safety, but it might create the illusion of it for users.

That said, good catches in the README, could you push those to master in a separate commit?

[SimenB]

Good point, it only works in combination with choices. Thanks for the discussion!

That said, good catches in the README, could you push those to master in a separate commit?

Sure: 5fd76f1