Lock File Management Rules

This rule applies to files matching the patterns above.

# Lock File Management Rules

## Rule
Always commit package-lock.json to version control. Use `npm ci` (not `npm install`) in CI and production builds. Keep exactly ONE lock file per project — never mix npm and yarn lock files.

## Commands
| Context | Command | Why |
|---------|---------|-----|
| Development | `npm install` | Updates lock file as needed |
| CI / Build | `npm ci` | Clean install from lock file |
| Add package | `npm install <pkg>` | Updates package.json + lock |
| Update all | `npm update` | Updates within version ranges |
| Audit fix | `npm audit fix` | Patches vulnerable versions |

## Good Examples
```bash
# CI pipeline — always use npm ci
npm ci
npm run build
npm test

# Adding a new dependency
npm install zod
git add package.json package-lock.json
git commit -m "chore: add zod for input validation"

# Updating dependencies
npm update
npm test  # Verify nothing breaks
git add package-lock.json
git commit -m "chore: update dependencies"
```

## Bad Examples
```bash
# BAD: npm install in CI (modifies lock file, slow)
npm install
npm run build

# BAD: Not committing lock file
echo "package-lock.json" >> .gitignore  # NEVER do this

# BAD: Multiple lock files
package-lock.json   # npm
yarn.lock           # yarn — pick ONE
pnpm-lock.yaml      # pnpm — pick ONE

# BAD: Deleting lock file to "fix" issues
rm package-lock.json && npm install  # Creates inconsistent deps
```

## .gitignore
```gitignore
# Commit your lock file — NEVER ignore it
# package-lock.json  <- DO NOT add this line

# Do ignore node_modules
node_modules/
```

## Enforcement
- CI uses `npm ci` exclusively — never `npm install`
- Fail CI if package-lock.json is modified during build
- Lint for multiple lock files (only one allowed)