I'm looking for input from senior engineers who have more experience than me with large codebases and team workflows.
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 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.
What I have observed is that a project's popularity has almost zero correlation to the amount of effort behind it, or how well done it is. You just need to get lucky. Maybe one person noticed your utility, invited you to some podcast, and then your repo explodes in popularity.
One thing I can tell you is that you should stop seeking to get notoriety, because the effort you are spending on that is effort you don't spend in improving your open source tools. I know it is probably quite frustrating, but you just have to continue building stuff in public and hoping to get noticed at some point.
Thanks for the advice, and i think you are 100% right.
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 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.
One really nice thing in varlock for monorepos is the import syntax. This lets you have shared config at the root, or just to break things up however you need. No need for diffing or copy pasting, as the schema validates everything - if something is required, it will yell at you.
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.
reply