Motherload solves the typesafe .env problem (getting autocompletion on process.env), no schemas required. 1. Import a .env file 2. That's it

Docs 👇

Wonder of this could be a potential attack vector down the line …

Could you show an example using your real .env file? 👀

Don’t you want a schema here though? So you can make sure they are what you expect at runtime and fail quickly if they’re not

I have an idea instead of importing .env file with secrets, let us import .env.schema then replace the schema format of @varlockdev with zod eg: # z.enum(["dev", "prod"]).default("dev") NODE_ENV= # z.string().optional() EXPORT=

Validation and agent-safe?

No thanks

How does it handle different .env (or any data file) contents between where you do the typechecking (dev, CI) and at runtime (prod)? Feels like it's missing a schema for true type-safety: import "./.env" with { schema: z.object({ ... }) }

But we need Zod to verify validity of content anyway, and it better be a func call rather than a module side effect. Am I missing something here? p.s. except that it’s really cool

What happens to a variable that only exists in production and is missing from the local .env?

Who needs this anymore?

Why .env import does not use named imports instead? import { port } from './.env'

importing is cool, type safety is questionable. having runtime safety is more important, like zod validation of env

incredible! is PORT inferred as a number?

not a replacement for schema validation then?

does it watch the file or is it a one-time import

I can't install anything with that name

It's a little meaningless for builds though that expect a matching env but now have no runtime validation 😢

That’s 🔥

importing the .env file directly feels illegal in a good way

😮

This has been a thing for a while. The scope of having typesafe is for the end-user to have the correct variables, enforcing minimum characters etc.

cooking again

This is insanely cool! Obviously orm-less sql is impressive but I hadn't even considered typesafe .envs Ironically had been attempting to find a nice setup with zod for this kind of thing previously.

When doing a `tsc` build, does the imported files reach the `dist` already as modules? Or we need to use node register hook for them to work at runtime?

just import the .env and you get autocomplete, no schema at all? nice

that's cool but I still would get value from zod for setting defaults, converting things like dates and numbers, and restricting values to a set of things (like log levels or aws regions)

You have made text file parsers and then give auto complete for SQL and now this. Have agents been some kind of unlock for you to be able to do this, or is it just you got to this idea only now?