menv-npm: Stop Chasing Missing Environment Variables

We've all been there: you clone a fresh repository, run npm install, hit npm run dev, and... it immediately crashes.

You dig through the logs and realize the app is missing half a dozen environment variables. You check the .env.example file, but it hasn't been updated in months. You end up DMing a teammate for their .env file, potentially trading secrets over Slack, just to get the thing running.

It’s a bottleneck that kills momentum and introduces unnecessary risk. That’s exactly why I built menv-npm.

The Practical Bottleneck

When you're working solo, managing environment variables is easy. But the second you add a teammate or a CI/CD pipeline, the "entropy" starts.

Things stay in sync for a week, and then someone adds a new Stripe key or an AWS region. They forget to update the example file, and suddenly the build fails in production, or the new hire spends their first four hours just trying to get the app to boot.

I got tired of these "it works on my machine" moments. I wanted a tool that didn't just store variables, but proactively managed the workflow around them.

Why I Built This (and Why You Should Use It)

menv-npm isn't just another wrapper for dotenv. It’s a need-based tool designed to solve three specific problems:

1. The "Ghost" Variable Problem

Ever deployed code only to find out a required variable was missing? menv-npm check is designed for your CI pipeline. It validates that every key in your template actually exists in the environment before you even start the build. If something is missing, it fails fast, saving you from runtime crashes.

2. The Outdated Template Problem

Manually updating .env.example is the first thing people forget to do. With the real-time watcher in menv-npm, your example files are updated automatically as you modify your local environment. It mirrors the structure without ever exposing the actual values.

3. The Accidental Leak

This is the big one. We’ve all seen (or been) the person who accidentally commits a .env file to GitHub. menv-npm doctor scans your local setup for known secret patterns—like AWS keys or Stripe tokens—and the CLI itself ensures your environment files are tucked away in .gitignore automatically.

The 5 Key Scenarios

To keep things practical, here are the five main ways menv-npm actually saves your skin:

generate: When you first set up a project or add a new batch of variables. It scrapes your .env and builds a clean .env.example so you don't have to do it manually.
```
npx menv-npm generate
```
sync: Use this to see if your local environment has drifted from the team template. It’ll tell you exactly what’s missing or extra.
```
npx menv-npm sync
```
check: The "Gatekeeper." Run this in your CI/CD pipeline. It validates that all required variables are present before deployment, stopping a broken build from ever hitting production.
```
npx menv-npm check
```
watch: For the active developers. It sits in the background and updates your example files the moment you hit "Save" on your .env file.
```
npx menv-npm watch
```
doctor: The security audit. It scans your environment files for accidentally pasted AWS keys, Stripe secrets, or GitHub tokens, helping you catch leaks before they get committed.
```
npx menv-npm doctor
```

Practical Use Cases

Onboarding a New Dev: Instead of a "Welcome to the team" DM with a list of secrets, the new hire just clones the repo and sees exactly what they need to provide based on the auto-generated example file.
Feature Branches: When you add a new service (like Redis or Mailgun) on a branch, menv-npm ensures that everyone who pulls that branch later knows they need those new keys.
SaaS Multi-tenancy: If you're managing different keys for different environments (Staging vs. Production), you can use the sync tool to ensure no production keys ever leak into your staging .env.
CI/CD Integrity: Automated deployments often fail because of a typo in a variable name on the server. menv-npm check catches these typos during the build phase.
Legacy Cleanup: Inheriting an old project? Run doctor to see if the previous devs left any sensitive keys lying around in plain text.

At the end of the day, engineering is about reducing friction. I didn't build menv-npm because I love configuration files; I built it because I want to spend my time building features, not debugging missing strings.

If you’re working in a team or trying to keep your CI/CD pipelines honest, give it a shot. It’s small, it’s fast, and it’ll save you at least one "Slack-me-your-env" conversation a week.

Explore the Interactive Demo

Check it out on NPM or contribute to the project on GitHub. If it helps your workflow, feel free to drop a ⭐️ to help others discover it!