Migrate codebase to TypeScript

[af]

Migrate codebase to TypeScript

[KATT]

I'm keen to have a go at this!

[af]

TBH I like the changes for the most part. I'm not sure how much people use those missing features but the only things I would miss personally are:

• colorized CLI output (chalk is overkill for this anyways, but colors are nice for readability in the terminal)
• errors from the Proxy (could maybe create extension points that make this possible in "userland"?)

I'll take a closer look this weekend but I'm intrigued by the idea of this being a v7. Curious if any of those features are a "dealbreaker" for anyone.

[KATT]

But I might approach it a bit differently as I use envalid in the browser a lot. I'd like it to be:

• Strict by default
• Have no dependencies
• No useage of proxy

[SimenB]

That's a separate discussion from migrating to TS - ideally a TS migration should have no logic changes

[KATT]

Yeah, you're right, I snowballed a few different discussions in there.

[SimenB]

That said, would love a PR migrating to TS and an issue discussing potential changes 🙂

[KATT]

What's your opinion on using tsdx to reduce boilerplate?

[SimenB]

Up to @af, but if it helps us get up and running we can always rip it out later

[af]

This sounds great! I agree with SimenB that we should limit the breaking changes as part of the conversion. Ideally the conversion could happen without requiring a major version bump. Personally I agree the lib should be strict by default, but we should move that to a separate discussion.

On the dependencies side, this lib was never initially intended for browser usage, so it's not optimized for that case dependency-wise. According to bundlephobia something like 50% of the bundle size comes from the chalk dependency, which could easily be replaced by creating a couple small helper functions to add the ANSI color codes.

[KATT]

Hey again! So, it was easier for me to start from scratch and add things gradually than to get it working here so it resulted in a new repo as you can see here: https://github.com/KATT/envsafe

Which then also led me to change some things to how I'd like it 😬 ... overall it's very similar but kinda slimmed down the API-surface, it's all in TypeScript and no third party deps added (yet).

What I'm "missing" right now is:

• host-support
• the testOnly-thing
• non-strict mode & the proxy-stuff that throws error
• chalk

How do you think we should proceed? I have a feeling like the changes are too major for you to want it in as it is, so maybe we keep it as two sister projects?

[KATT]

I'm very happy to pass this back into envalid and burn that project if you like it, but I don't know if you like the changes, want to do a major version, etc.

[KATT]

Great to hear! I'd prefer to have one-package-to-rule-them-all rather than adding more fragmentation.

• I've added the proxy, but I already want to refactor it to just expose freezeObject so the logic is not always included in the bundle when using it in the browser
• If there's a way (that doesn't take a day of configuration) of conditionally including chalk depending if node/browser it'd be nice. Colors are nice indeed!

Other notable changes:

• The first arg is now the options and env is optional in the options obj with process.env as default.
• Added input to help with environments where you can't iterate on the process.env - but I'm working on a webpack plugin which could replace it and also make the build fail at compile time rather than at runtime.
• I removed process.exit(1) and simply throw the error as it gives better error messages in CI - exit propagates exit(1) anyway

Removed:

• host
• No built-in dotenv-stuff. Can just require('dotenv') before calling envsafe()
• transformer - I don't see the point. If you wanna transform the object after creating the env, just do it, I don't see why an API is needed for it.
• No second arg on makeValidator - didn't see the point.

[af]

Update: I finally had some time to check this out over this last weekend. Thanks @KATT, looks great and while I think overall it's a big step forward, to reduce churn for existing users I think we should roll the changes into the existing API. My WIP isn't in a reviewable state yet, but hopefully will be in a couple of days. Wanted to get feedback on the following plan though:

Major changes I think we should incorporate:

• Rewrite in TypeScript (obviously)
• Use tsdx to simplify tooling, including migrating tests to jest (I still like painless but it's abandoned 😢 )
• Remove all runtime dependencies. The value they bring right now is not (IMO) worth the cost for client-side users (who are more numerous than I ever anticipated). As you mentioned, dotenv can just be used before passing the env object into envalid. The other deps are really just providing minor conveniences, and being dependency-free would be great
• Introduce the concept of "middlewares", which basically do the same thing as transformer does now. The proxy and isDev/isProd/etc properties can probably be re-implemented as middlewares to make things more modular
• Turn on strict behavior by default and remove the option. If you want to preserve existing non-strict behavior, you can turn off the proxy middleware and do something like const output = { ...process.env, ...cleanedEnvFromEnvalid }

However I don't want to do a full rewrite of the API; the churn would probably be too annoying for existing users. That means:

• Keep all existing validators, including host. host and ip rely on an existing package currently, but a simplified version can be rolled into envalid. If a user wants more exhaustive checking, they can use a custom validator to recreate the v6 behavior
• Keep as much of the existing test suite as possible
• Minimize overall api changes unless they're unavoidably tied to the benefits above

[KATT]

Sounds like good plan! I'm happy to take a look at your WIP whenever.

[af]

@KATT Just pushed up a WIP PR, would love your feedback 👍

[af]

Finally done as of v7.0.0-beta.1