[email protected] introduces breaking change about envalid HOT 6 CLOSED

Hi @SimenB ,

Thanks for your reply. Our use case was Validator.EnvMissingError. I'll see to a PR.

Thanks,

Simon

from envalid.

@af probably has opinions here - personally I think it's fine adding them directly to the envalid export.

(remember to update the TS typings as well 🙂)

from envalid.

I'm fine with adding them to the export like that. I don't think a major version increase is warranted though, importing internal paths is not officially supported by the API.

from envalid.

We don't support private imports, so I wouldn't call this a breaking change (it's not documented).

However, if you need to import validators, happy to take a PR exposing it as require('envalid').validators; or something like that.

A use case would be to get EnvError and EnvMissingError I guess. Maybe it's enough to expose those separately?

from envalid.

I'm looking at envalid's code but am not quite certain where your preference may lie in terms of making validators available externally. The simplest may be this code in envalid.js immediately before the module export, but I doubt that's preferential:

const { EnvError, EnvMissingError } = require('./validators');
envalid.EnvError = EnvError;
envalid.EnvMissingError = EnvMissingError;

from envalid.

Much appreciate the nice collaboration, folks. Thank you!

from envalid.