@BSenta

Thanks for giving a shout out to the engineer that actually built it

@rumisbadforyou9670

So you've reinvented config files again? Good job, it only took you 40 years šŸ„³

@pythagoran

I used to have to `export FOO=bar`
But now I can add a new library, boilerplates, types, and build steps!
Job security achieved.

@0xtz_

Man I was hoping to find this outside T3 šŸ˜‚

@CottidaeSEA

I believe the issue with environment variables is generally that you don't know you need them until something breaks, then you need to find out what the values should be.
It is simply pain, and if not documented properly you'll just cry yourself to sleep at night.

@souvlaki42

This package seems promising enough. I had similar issues with env files. I just used the cleanEnv function from the envalid package to fix them.

@kiryls1207

6:04 the infamous dev pain

@spotgaming4668

That red swiggly line is one of the best creative thing, give a pat yourself on the back

@riser9644

Guys is this not over engineering

@SeanCassiere

Been ripping ct3a zod env stuff for awhile now, so it's great to have this.

Also, how is the Next starting template sooo bad??? Like ct3a without ANY of the options feels waaay better than the Next default one.

@Leon-bb8fc

How is everyone OK with this... .env could be troublesome sometimes, but importing two new libs to just type check and pre-build validation???

@anush8

Oh my god. Please, don't you ever get bothered by the boilerplate? Like micro-optimizing everything makes everything esoteric and that's just terrible.

@crowlsyong

0:43 little things like giving credit where credit is due...it's super important. thanks for being a good dude.

@agenordebriat

And of course nexxel is already there with the Nuxt adapter/integration PR! šŸ„µ

@andrewc8125

Such useful info! Thank youšŸ˜ŠšŸ˜Š

@kaleabmelkie

Env vars are a mess in React. This just makes me really appreciate the SvelteKit way (fully typed, checked at build because they're just direct imports, server/public separation). I like how this library has validation tho.

@UocLv

Man, more crap to do basic stuff. Just stop. Less is more!

@ES-eb6pb

bloatware...

@CommenterAccount

I frequently use env variables to tree shake in different envs at compile time. For example, any place you have process.env.NODE_ENV compiles to the actual value like "development", which tree shaking will interpret as a literal, which means "if ("development" === "production")" will tree shake out any code in this conditional. The approach in this package requires a runtime check which does not allow for tree shaking. Any thoughts on this tradeoff for this approach?

A common example is for things like integrated devtools that I don't want shipped to production

@jvliwanag

One thing iā€™ve been looking for is how to detect changes on the settings and have the system reactively adopt the new setting.

For ex - new timeout setting just applies it the api client. But a database url change re-establishes a db connection pool to a new server.