Ah, I stand corrected! The varlock run -- approach and the standalone binary completely solve the vendor lock-in concern I mentioned.
I have to say, patching console and http in JS to auto-redact sensitive data based on the schema is genuinely brilliant. Leaking secrets in logs is a massive pain point, and handling it automatically at the tool level is a great solution.
Really impressive work on the entire toolkit. It’s definitely a much more comprehensive ecosystem than what I built. I appreciate you taking the time to explain the architecture—definitely taking some notes from this!
Thanks for sharing varlock, it looks really solid! The .env.schema approach is a great way to guarantee strict type safety and a single source of truth.
I think the main philosophical difference here is where the validation happens. If I understand correctly, varlock integrates directly into the application's config loading process. That’s incredibly powerful for runtime safety.
My goal with env-rx was to build something completely detached from the application runtime. I wanted a drop-in CLI utility that requires absolutely zero code changes or new dependencies in the actual app. You just throw it into a GitHub Action or a pre-commit hook, and it screams at you if a variable is missing before the code even builds.
But I really like your approach to having a unified schema instead of just comparing against an .example file. Definitely taking some notes from how varlock handles this!
I have to say, patching console and http in JS to auto-redact sensitive data based on the schema is genuinely brilliant. Leaking secrets in logs is a massive pain point, and handling it automatically at the tool level is a great solution.
Really impressive work on the entire toolkit. It’s definitely a much more comprehensive ecosystem than what I built. I appreciate you taking the time to explain the architecture—definitely taking some notes from this!