.gitignore for a Node.js Project

A .gitignore file is one of the first files you should create in any new project, ideally before the first commit. Its primary purpose is to prevent accidental commits of files that should never be in version control: dependency directories that can be regenerated, build outputs that change on every compile, environment files containing secrets, and editor/OS-generated metadata that's specific to each developer's machine. Getting it wrong means cleaning up sensitive data or hundreds of megabytes of generated files from git history, which is painful and time-consuming. This example covers the full Node.js ecosystem. node_modules/ is the highest-priority entry — this directory can contain tens of thousands of files and hundreds of megabytes for a typical production application. It should never be committed because it's fully regenerated by npm ci or yarn install from the committed package-lock.json or yarn.lock. Build output directories (dist/, build/, .next/, .nuxt/, out/) contain compiled, bundled, and optimized files generated by your build tool. These are environment-specific (source maps may contain absolute paths), often large, and change on every build — none of which is appropriate for version control. Your deployment process should build from source code, not from committed artifacts. Environment file patterns (.env, .env.local, .env.*.local) are critical to get right because these files contain API keys, database passwords, and other credentials that would become exposed if committed to a public repository. The pattern .env.*.local uses a glob that matches .env.development.local, .env.test.local, etc. — all local environment overrides. TypeScript-specific entries: *.tsbuildinfo is the TypeScript build state file used for incremental compilation. It's a large binary file that's machine-specific and regenerated on each build. Most TypeScript projects should ignore it. Editor directories (.vscode/, .idea/) contain personal editor settings, workspace configurations, and plugin states. While some teams share a minimal .vscode/settings.json for consistent editor behavior (indentation, formatting), the full .vscode/ directory contains user-specific files that conflict across different developers' setups. A middle ground is to gitignore the full directory but add .vscode/settings.json back with git add -f. OS-generated files: .DS_Store is macOS's directory metadata file that stores folder view settings. Thumbs.db is Windows's thumbnail cache. Neither belongs in version control, but rather than relying on individual developers to add them, consider adding them to a global gitignore file (~/.gitignore_global) that applies across all repositories. Tips: run git status before committing on a new project to verify the .gitignore is working correctly and no unwanted files appear as untracked. Use gitignore.io or the GitHub gitignore collection to generate comprehensive templates for your specific stack.

Example
# Dependencies
node_modules/
.pnp
.pnp.js

# Build outputs
dist/
build/
.next/
.nuxt/
out/

# Environment files
.env
.env.local
.env.*.local

# Logs
*.log
npm-debug.log*
yarn-debug.log*

# TypeScript
*.tsbuildinfo

# OS
.DS_Store
Thumbs.db

# Editor
.vscode/
.idea/
[ open in .gitignore Generator → ]

FAQ

Should I commit node_modules to git?
No. node_modules can contain thousands of files and hundreds of megabytes. Always add it to .gitignore and rely on package.json and the lock file to restore dependencies with npm ci.
How do I ignore already-committed files?
Adding a file to .gitignore only prevents future tracking. To stop tracking a file already in git, run git rm --cached filename and then commit the removal.
Can I use a global gitignore for OS files?
Yes. Configure a global ignore file with git config --global core.excludesfile ~/.gitignore_global and add .DS_Store, Thumbs.db, and editor directories there so they apply to every repository.

Related Examples