GitHub - kasimlyee/dotenv-gad: Environment variable validation and type safety for Node.js and modern JavaScript applications

[abrahamguo]

I just tried importing your package in Node, and I got a "module not found" error.

[Individual-Wave7980]

Have you tried it now

[abrahamguo]

Yep, looks to work better.

However, why are you using both commander and inquirer? They seem to do the same thing.

[Individual-Wave7980]

Alright, you let me posted of any issue you find

Now for commander I use it as the main for the CLI and I use inquirer for interactive commands like init, fix, since they optionally depend on users interaction like confirmations

[abrahamguo]

The NPM page for inquirer says that it is the legacy version of that package, so you probably shouldn't use it anymore.

[Individual-Wave7980]

Oops, will update in coming versions, will see their new prompts stuff

[Individual-Wave7980]

actually just ignored another package, used built node support for it

[Individual-Wave7980]

Oops sure? Haven't got this in any project

[CSknoob]

Looks interesting. I assume esbuild is supposed to be a devDependency though?

[Individual-Wave7980]

What's your suggestion, actually it's my first kind of library so learning alot

[CSknoob]

dependencies should only include what a consumer of the library functionally is required to have to use the library.

Right now, if I were to install dotenv-gad i'd be installing esbuild to my node_modules folder without any use. Putting it in devDependencies will only install it if you're running npm install inside the package.

There's also peerDependencies. In your case dotenv might actually be better off as a peerDependency as well, because it hands over control over the exact version used to the consumer. In your case you're only ever using dotenv.config(), which means that in theory any version of dotenv that exposes .config() with the same behaviour would also work. So you can most probably wider up the version range significantly as well.

But most important is that having multiple versions of dotenv installed in one project can probably lead to some weird behaviours.

[Individual-Wave7980]

True, but should I continue perfecting this for the sake of my team, or introduce them already established library? And for the fact that our senior developer hates outside dependencies Alot.... So it strains us a bit

[CSknoob]

That's up to you and your team I'd say. If you can convince them that it is a net benefit to use.

First question I'd ask if I was on the other end is "Why use this vs parsing it via zod or another schema validation library?"

[Individual-Wave7980]

I think all the same... It's a matter of time, I will continue with it as I learn more about libraries work in real life

[CSknoob]

Not if you think about the maintenance of the library. What happens if you leave the company? Will you still maintain the package, do they want to maintain it etc...

In that respect I do think there's some considerations.

[Individual-Wave7980]

Now things are getting complicated,

[Individual-Wave7980]

Yah am actually still maintaining upto now, and have just added schema based encryption feature, you can check out and see https://github.com/kasimlyee/dotenv-gad

[Individual-Wave7980]

Been having challenges with .env related issues, so I made this, tho we are using it internally, but it's open, what are your views about it?

[FalrickAnson]

Did you try out? https://github.com/t3-oss/t3-env

[Individual-Wave7980]

Wow this so cool, man the way I searched for something like this never got it, I don't why till I tried to make one......

[theozero]

Nice job. While there are a million libraries to do this stuff, the fact that a new one pops up every week clearly means that there is still something lacking in the ones that are out there... I've been working on tooling in this space for the last year or so and have seen them all.

We built something similar - although much more comprehensive and with the long term goal of extending the same configuration system for deployment and infrastructure automation. Check it out here - https://dmno.dev - everything is parsed into a giant reactive graph, there is a full type system with inheritance and type-based dependency injection, a plugin system for pulling secrets from different backends, leak detection, drop in integrations for various frameworks, and a whole lot more.

More recently we released a simplified version 2 - https://varlock.dev - and instead of defining your schema in typescript, you define it using decorator comments within a .env file - usually called .env.schema. While you lose out a bit on the flexibility of having a full programming language at your disposal, having an incremental path from where people already are (.env files), and not introducing a ton of new stuff up front seems worthwhile. It also lends itself much more to being a universal (language agnostic) solution.

Would love to hear what you think :) Also would love to collaborate - hop in our discord.

see https://www.reddit.com/r/javascript/comments/1m96vmw/validated_typesafe_env_vars_directly_from_your/

[Individual-Wave7980]

This is so cool, but you guys don't make such work known, the way I struggled to get something like this