import os
import re
from pathlib import Path
from typing import Dict, List, Tuple

def scan_env_files(project_root: str) -> Dict[str, List[str]]:
    """
    Scan all .env* files in project and find naming inconsistencies.
    Returns dict with variable names and their inconsistent variations.
    """
    env_files = list(Path(project_root).glob(".env*"))
    variable_map = {}
    
    for env_file in env_files:
        if env_file.is_file():
            with open(env_file, 'r') as f:
                for line in f:
                    line = line.strip()
                    if line and not line.startswith('#') and '=' in line:
                        var_name = line.split('=')[0].strip()
                        normalized = normalize_var_name(var_name)
                        
                        if normalized not in variable_map:
                            variable_map[normalized] = []
                        
                        if var_name not in variable_map[normalized]:
                            variable_map[normalized].append(var_name)
    
    # Return only variables with inconsistencies
    return {k: v for k, v in variable_map.items() if len(v) > 1}

def normalize_var_name(var_name: str) -> str:
    """Normalize variable name to lowercase with underscores"""
    # Convert camelCase to snake_case
    var_name = re.sub(r'([a-z])([A-Z])', r'\1_\2', var_name)
    # Convert to lowercase and replace hyphens with underscores
    return var_name.lower().replace('-', '_')

# Usage example:
inconsistencies = scan_env_files("./my-project")
for base_name, variations in inconsistencies.items():
    print(f"{base_name}: {', '.join(variations)}")

The Problem: Your .env Files Are a Lawless Wasteland

Let's be honest: your project's .env files look like they were written by a committee of cats walking across keyboards. You've got DB_HOST in your local .env, DATABASE_HOST in staging, and database_host in production because someone decided snake_case was "more readable" after their third espresso. Meanwhile, your CI/CD pipeline is failing with cryptic errors that make you question your career choices.

Why does this happen? Because every developer brings their own "brilliant" naming convention to the party. Frontend devs love screaming snake case (API_KEY), backend engineers prefer lowercase with underscores (api_key), and that one contractor who left six months ago used camelCase (apiKey) because they "wanted to be different." The result? A configuration nightmare that wastes more developer hours than unnecessary meetings.

Consider this tragic comedy: your app works perfectly on Alice's machine with her REDIS_URL, fails on Bob's machine because he's using redis_url, and crashes spectacularly in production where someone decided RedisConnectionString was the way to go. You're not debugging code anymore—you're playing configuration detective, and the clues are written in invisible ink.

The Solution: Enter the Drifting Config Samurai

I built .env-ronin: The Drifting Config Samurai to solve this exact problem. This isn't another linter that gently suggests you might want to consider consistency. This is a tool that walks into your project, assesses the chaotic state of your configuration files, and brings order through either gentle persuasion or, when necessary, automated enforcement.

How does it work? The ronin scans all your .env* files—yes, including .env.local, .env.production, and that mysterious .env.backup_2022 file someone forgot to delete. It analyzes variable naming patterns, identifies inconsistencies, and presents you with options to standardize everything. Think of it as a configuration therapist who's not afraid to call out your team's bad habits.

Despite the humorous framing, this tool is genuinely useful. It catches those subtle bugs before they reach production, reduces onboarding time for new developers (who won't need to decipher your team's bizarre naming conventions), and eliminates those "works on my machine" conversations that waste everyone's time. The ronin doesn't just point out problems—it offers solutions and can even implement them with your approval.

How to Use It: Bringing Honor to Your Codebase

Getting started with .env-ronin is simpler than explaining to your manager why production is down. First, install it globally or as a dev dependency:

npm install -g env-file-linter
# or
yarn global add env-file-linter

Then navigate to your project directory and run the ronin:

env-ronin scan

Here's a snippet from the main scanning logic that shows how it identifies inconsistencies:

// From the scanner module
function analyzeEnvFiles(envFiles) {
  const variableMap = new Map();
  
  envFiles.forEach(file => {
    const variables = parseEnvFile(file);
    variables.forEach((value, name) => {
      const normalized = normalizeVariableName(name);
      if (!variableMap.has(normalized)) {
        variableMap.set(normalized, new Set());
      }
      variableMap.get(normalized).add(name);
    });
  });
  
  // Find inconsistencies where same variable has different names
  return Array.from(variableMap.entries())
    .filter(([_, variations]) => variations.size > 1);
}

Check out the full source code on GitHub to see all the clever ways the ronin handles edge cases and provides actionable feedback.

Key Features: The Ronin's Arsenal

• Scans all .env* files in a project and flags naming inconsistencies: No file is safe from the ronin's gaze. It'll find every variation of your environment variables across all configuration files.
• Suggests standardized naming based on majority rule or a config file: The ronin can follow the wisdom of the crowd (what naming pattern appears most frequently) or adhere to your custom rules defined in a .env-ronin.config.js file.
• Can auto-rename variables (with confirmation) to bring consistency: Once you approve the suggested changes, the ronin will update all your .env files to use consistent naming—no manual find-and-replace required.
• Generates a 'shame report' showing which team member's files are the most deviant: This feature is optional but highly entertaining. It creates a report showing whose .env files deviate most from the standard, perfect for friendly team ribbing or identifying who needs configuration training.

Conclusion: Restoring Honor to Your Configuration

.env-ronin isn't just another tool in your development toolkit—it's a cultural shift toward configuration sanity. By standardizing your environment variable naming, you eliminate a whole category of bugs, reduce onboarding friction, and make your codebase more maintainable. Plus, you'll never have to explain to your team lead why the database connection failed because someone used DbHost instead of DB_HOST.

The best part? It's completely free and open source. Try it out today: https://github.com/BoopyCode/env-file-linter. Your future self—the one not debugging environment variables at 2 AM—will thank you.

Remember: in the world of software development, consistency isn't just a virtue—it's the difference between shipping features and debugging why Bob's machine "is special." Let the ronin bring honor to your codebase, one environment variable at a time.