.env.sample

API_KEY=
DB_HOST=
DB_USER=
DB_PASS=
MODE=

While .env.sample is dominant, some alternatives exist:

Use .env.sample unless:

In Continuous Integration, you don't have production secrets. But you need valid values to run tests. You can source the .env.sample (with dummy data) inside your test pipeline to ensure the build doesn't fail due to missing variables.

require('dotenv').config();
const dbUrl = process.env.DATABASE_URL;
if (!dbUrl) 
console.error('Missing DATABASE_URL in .env file');
process.exit(1);
 .env.sample

Better: add validation libraries like envalid or joi to check that all required variables exist at startup.

.env.sample (or .env.example) is a template file that shows what environment variables the application expects, without including sensitive or environment-specific values. It is committed to version control and serves as documentation. API_KEY= DB_HOST= DB_USER= DB_PASS= MODE=

Example .env.sample:

DATABASE_URL=postgresql://user:password@localhost:5432/database_name
API_KEY=your_api_key_here
NODE_ENV=development
PORT=3000

Compare to the actual .env (kept private):

DATABASE_URL=postgresql://admin:Super$3cret@prod-db:5432/sales
API_KEY=sk_live_7Fj29kLmNpQrStUvWxYz
NODE_ENV=production
PORT=8080

The sample file communicates shape, not secrets. Variable names (uppercase

SESSION_TIMEOUT=86400

NODE_ENV=development

• Variable names (uppercase, underscores): DB_HOST, API_KEY.
• Example or placeholder values (not real secrets): DB_PASSWORD=changeme
• Comments explaining purpose and format: