https://github.com/Chrilleweb/vscode-dotenv-diff
I recently published a VS Code extension for dotenv-diff, this is quite simpler than the dotenv-diff npm package.The problem: you don't always want to install a dependency.The solution: a VS Code extension so you don't have to install a dependency — it just works out of the box.This version of dotenv-diff is simpler, it simply does:- Warn when you have an environment variable that is used in...
https://dotenv-diff-docs.vercel.app/
Hi HNThis is the documentation site for dotenv-diffIt’s a CLI tool that scans you’re codebase for environment variable usage in you’re codebase and detects issues about them.Example: in Next.js using a non NEXT_PUBLIC environment variable in a client file just returns undefined - no context why.I’ve personally wasted hours debugging issues like that.
Hi HN,I’ve been curious about this as I recently started maintaining my open source project.I’m trying to understand what actually makes people decide to contribute to projects in particular — not the big, well-known ones.For context: I’ve tried to do the “obvious” things — writing a clear README, keeping the scope focused, adding tests and CI, and labeling a few issues as...
:)
I’ve been working on a small open source CLI tool in my spare time and recently reached a point where it feels “done enough” to share — but I’m unsure what the right next steps are.
So far I’ve tried: - Writing a clear README with examples - Adding documentation and usage guides on my docs website - Sharing it in one or two relevant discussions (without spamming)
I’m explicitly not trying to market it aggressively — I’d rather get it in front of the right people and receive honest feedback.
For those of you who’ve shipped open source projects that actually got adopted: What made the biggest difference early on? What do you wish you had done sooner?
If it helps, the project it's the link if you have any tips
Thanks!
I recently built a small open source CLI tool that scans a codebase for environment variable issues (missing env vars, unused vars, framework-specific mistakes like Next.js / t3-env, etc.).
I’m not trying to grow users yet — I’m mainly looking for honest technical feedback: - Is the problem real? - Are there obvious flaws in the approach? - Could this be used in your workflow?
For people who’ve shipped OSS tools before: What worked best for you when gathering early feedback from experienced developers?
Thanks!
I built a CLI tool that scans the codebase and warns about these problems automatically. It also detects framework-specific rules for Next.js and SvelteKit.
The tool i have build works well in my job where we have a turbo monorepo — but I genuinely don’t know if this is something experienced teams would ever rely on, or if there's already a better approach in the real world.
i am already working as a software developer, so the only reason that i want it to get noticed, its because i just think its cool to have made something other people find useful. And i love programming, and this project is definitely making me a better software developer, with or without tons of downloads or stars :)
Just wanted to make sure that i didn't do anything miserable wrong
I recently released an open-source tool that solves a real problem I kept running into, and now I’m wondering how other developers get visibility for their projects.
I'm not trying to “promote” anything here — I’m genuinely curious about the process. I’ve posted on GitHub Discussions and Reddit, but it’s still hard to get people to notice a new repo unless it randomly hits the right place at the right time.
Do i need to do anything else on my repo?
I am currently working on a turbo mono repo frontend on my work with maybe 20-25 different env variables. Here the dotenv-diff is really a game changer, but yea for smaller projects, i might be a bit overkill.
I like the projects you have linked, i will try to see if they have any need to have features that i could use
in `dotenv-diff` you also have the --compare option which will compare your .env whit your .env.example to keeping them in sync, while also have the amount of scanning features that keeps the project safe.
I recently built a tool that I personally needed for my own projects, and now I’m super curious if other developers would actually find it useful.
It’s called dotenv-diff, and the main feature is a codebase scanner that finds problems with environment variables before they break things.
Why I built it
I kept seeing the same issues in real projects:
Feature breaks because .env is missing variables
New developer joins → app crashes due to missing env
.env.example goes out of sync
Someone accidentally leaves a secret inside a TS file
Frontend frameworks misused env naming (NEXT_PUBLIC, VITE_, etc.)
I wanted one CLI command that gives me a full health check of environment usage in my project.
Honest question:
Would this be useful in your workflow?
If you want to check it out:
npm package: https://www.npmjs.com/package/dotenv-diff Docs: https://dotenv-diff-docs.vercel.app