Added `t3-env` for typesafe environment variables

[albbus-stack]

This PR implements the use of t3-env in the next app, expo app (also added the EAS_SLUG variable) and in the packages folder for common variables. Fixes #90.

Currently I couldn't get it working for the api environment variables defined in the .dev.vars.

@timothymiller Do you have some suggestions on what could be going wrong on native? Web works fine. I also implemented the ThemeToggle component for native (currently commented out), if you could test that also would be great.

[albbus-stack]

Already encountering some errors with eas build, I'm going to move the env from packages to app.

[albbus-stack]

Maybe the environment checking in the expo folder doesn't make much sense, need some feedback on this. I'm referring to EAS_OWNER, EAS_PROJECT_ID, ...

[tonyabracadabra]

Thanks this would help a lot

[albbus-stack]

Now expo build succeeds but the app crashes on open with the t3-env error:

Seems like the environment variables don't get pushed to process.env by react-native-dotenv so t3-env doesn't find them. If you have some insights, please share them

[timothymiller]

We don't need t3-env for this functionality. We've also moved onto using Valibot over Zod.

My inspiration comes from this video: https://www.youtube.com/watch?v=q1im-hMlKhM

[albbus-stack]

Yeah that's nice, declaring them in the global scope seems the right way. In the near future I'm going to refactor all of this to this approach using valibot, removing t3-env and zod

[albbus-stack]

We don't need t3-env for this functionality. We've also moved onto using Valibot over Zod.

My inspiration comes from this video: https://www.youtube.com/watch?v=q1im-hMlKhM

I've implemented env-variables.ts files with valibot in the features, next and expo folders. Now the variables are typed and available in the intellisense.

Removed t3-env and zod. The only problem that remains is checking if the variables are present at build time, since this implementation doesn't do that currently (only parses their types). Do you have ideas on this?

[timothymiller]

👉 Expo loads env vars with the EXPO_PUBLIC prefix by default 👉 Next loads env vars with the NEXT_PUBLIC prefix by default 👉 Wrangler wants env vars inside .dev.vars

😩

I think we might have to write a transform to handle them all

https://docs.expo.dev/guides/environment-variables/

[albbus-stack]

👉 Expo loads env vars with the EXPO_PUBLIC prefix by default 👉 Next loads env vars with the NEXT_PUBLIC prefix by default 👉 Wrangler wants env vars inside .dev.vars

Yeah that's kind of a mess 😖

I think we might have to write a transform to handle them all

I have very small knowledge on how we could do that at build time, do you have any sources/ideas that I could take a look at?

[timothymiller]

I'm thinking about writing a small ts shim that will take a global .env file and move it to either the expo or next folder with the appropriate prefix during the UI package build time

[timothymiller]

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

[albbus-stack]

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe, at least for the next and expo ones?)

[timothymiller]

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe, at least for the next and expo ones?)

Generating them can be done, but it's the accessing them from the app folder that is awkward.

[timothymiller]

It introduces runtime overhead

[albbus-stack]

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe, at least for the next and expo ones?)

Generating them can be done, but it's the accessing them from the app folder that is awkward.

Yeah the problem is inside the app folder