Add edge runtime compatibility and allow custom formatters #15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #2, supersedes #9 and #11.
This PR adds support for non-Node runtimes via a new entrypoint,
znv/compat
. To accomplish this, I've added the ability to pass a custom reporter toparseEnv
, or more granular token formatters.The default entrypoint,
znv
, now exports a version ofparseEnv
that defaults to colorized tokens, which matches the current behaviour. This relies on Node'stty
module.The new
znv/compat
entrypoint exports a version ofparseEnv
that doesn't colorize any tokens; nothing in this codepath importstty
or any other Node module, so it should be compatible with serverless environments (and even browsers, if you somehow need environment parsing there).Additionally, I've removed the dependency on the
colorette
module and have instead added a simplified version of it for our own use.One small thing I'm unsure about is that I had to change the signature of the "internal"
parseEnv
:but the exported
parseEnv
that wraps the aboveparseEnvImpl
retainsRestrictSchemas<T>
, so everything should work the same:All this feels a little clunky, but I couldn't think of any other way to do this that doesn't add a bunch of other complexity. Alternate suggestions welcome!
Please take a look if you're one of the people who requested serverless support for
znv
! I've published it to npm under thenext
tag, so you can usenpm i znv@next
to try it out.