Node.js .gitignore Template
A properly configured .gitignore file is one of the first files you should create in any Node.js project. Committing the wrong files to a repository causes several categories of problems: security exposure (environment variables and API keys committed in .env files have caused major breaches), repository bloat (node_modules can exceed 500MB and should never be committed), and merge conflicts (IDE-specific files differ between team members and create unnecessary noise in diffs).
The node_modules directory is the most critical exclusion. It contains all installed dependencies, can contain hundreds of thousands of files, and is fully reproducible by running npm install. Committing node_modules causes repository sizes to grow into gigabytes, makes cloning slow, and interferes with npm linking for local development. Some developers accidentally commit node_modules when initializing a repository without a .gitignore in place — add the .gitignore before running npm install to prevent this.
Environment files (.env, .env.local, .env.production, .env.*.local) contain sensitive secrets and must never be committed. Patterns like .env* exclude all environment file variants. Always commit a .env.example with placeholder values and documentation so that other developers know what variables exist without seeing the actual secrets. The .env.example file is the canonical documentation for your environment variable schema.
Build output directories vary by toolchain. For Vite and Create React App projects, the dist or build directories contain compiled output. For TypeScript projects, the out or dist directory contains compiled JavaScript. For Next.js, the .next directory contains the build cache and compiled pages. For bundlers like webpack, dist is typical. None of these should be committed — they are generated artifacts that can always be regenerated from source.
Log files (npm-debug.log, yarn-debug.log, lerna-debug.log, *.log files generally) accumulate during development and are not version control artifacts. The .npm cache directory should be excluded. The yarn.lock file and package-lock.json files are a special case: these should be committed for applications (to ensure reproducible installs) but excluded or carefully managed for libraries (to avoid imposing lock file constraints on consumers).
Editor-specific files from VS Code (.vscode), JetBrains IDEs (.idea), and Vim (.swp, .swo) should be excluded. Some teams prefer to commit shared .vscode/settings.json and .vscode/extensions.json to standardize editor configuration — in this case, exclude .vscode/* but unexclude the specific files you want to share using negation patterns.
Template Preview
{"environment":"node","includesNpmCache":true,"includesEnvFiles":true,"includesBuildOutput":true,"includesEditorFiles":true,"includesOSFiles":true,"packageManager":"npm"}Customize this template with your own details using the free generator:
▸Open in GeneratorFAQ
- Should I commit package-lock.json or yarn.lock?
- Yes, for applications you should commit lock files. Lock files record exact dependency versions, ensuring that every developer and CI environment installs the same versions and eliminating "works on my machine" dependency bugs. For libraries published to npm, committing the lock file is debatable — it does not affect consumers who install your package, but it does standardize development environments for contributors. Most library projects commit it.
- I accidentally committed node_modules — how do I remove it?
- Add node_modules to your .gitignore if not already present. Then remove it from tracking without deleting the local files: run git rm -r --cached node_modules. Then commit the removal: git commit -m "chore: remove node_modules from tracking". Finally, push the change. Other team members will need to run git pull and may need to re-run npm install if their local state is affected.
- Should I use a global .gitignore or a per-project .gitignore?
- Use both for different purposes. A global .gitignore (~/.gitignore_global configured with git config --global core.excludesFile) handles your personal editor files, OS metadata (.DS_Store, Thumbs.db), and any tools specific to your workflow. The per-project .gitignore handles project-specific generated files (build outputs, node_modules) and team-wide exclusions. This way you do not pollute the project .gitignore with your personal tool preferences.