Node.js .gitignore Template
When initializing a Node.js application, committing node_modules or secret environment files to version control causes repository bloat and severe security vulnerabilities. This template isolates all ephemeral cache, dependencies, and environment credentials.
| 1 | # Dependencies |
| 2 | node_modules/ |
| 3 | jspm_packages/ |
| 4 | |
| 5 | # Logs |
| 6 | logs/ |
| 7 | *.log |
| 8 | npm-debug.log* |
| 9 | yarn-debug.log* |
| 10 | yarn-error.log* |
| 11 | pnpm-debug.log* |
| 12 | lerna-debug.log* |
| 13 | |
| 14 | # Runtime data |
| 15 | pids/ |
| 16 | *.pid |
| 17 | *.seed |
| 18 | *.pid.lock |
| 19 | |
| 20 | # Build & compiled output |
| 21 | lib-cov/ |
| 22 | coverage/ |
| 23 | *.lcov |
| 24 | .nyc_output/ |
| 25 | build/Release/ |
| 26 | dist/ |
| 27 | build/ |
| 28 | .dist/ |
| 29 | |
| 30 | # Environment files |
| 31 | .env |
| 32 | .env.local |
| 33 | .env.development.local |
| 34 | .env.test.local |
| 35 | .env.production.local |
| 36 | *.env |
| 37 | |
| 38 | # Framework caches |
| 39 | .next/ |
| 40 | out/ |
| 41 | .nuxt/ |
| 42 | .vuepress/dist/ |
| 43 | .serverless/ |
| 44 | .fusebox/ |
| 45 | .dynamodb/ |
| 46 | .tern-port |
Key Rules & Why They Are Ignored
node_modules/Excludes thousands of downloaded npm dependency files from version control.
.env*.localPrevents accidentally pushing private API keys, database URLs, and secrets to GitHub.
dist/ and build/Transpiled/bundled production assets that are generated dynamically during build steps.
*.logEphemeral runtime error logs that change constantly on developer machines.
Already Committed Ignored Files? Purge from Git Cache
Adding a pattern to .gitignore does NOT delete files that were already tracked in previous commits. Run this command to remove them from tracking without deleting your local copies:
git rm -r --cached . && git add . && git commit -m "Untrack ignored files"Frequently Asked Questions About Node.js .gitignore
Frequently Asked Questions
Everything you need to know regarding specifications, syntax, and security best practices.
Yes! Always commit package-lock.json, yarn.lock, or pnpm-lock.yaml. They guarantee identical dependency resolution across all team members and CI/CD environments.