.gitignore Builder for Node.js

Generate a comprehensive .gitignore for Node, npm, and JavaScript projects

Builds a thorough Node.js .gitignore covering node_modules, .env files, build outputs, logs, coverage, editor folders, and OS artifacts, with toggles to include or skip each section. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why ignore node_modules?

node_modules is large and fully reproducible from package.json and the lockfile. Committing it bloats the repo and causes merge conflicts, so it is always ignored.

A complete Node.js .gitignore

Starting a Node project means deciding what not to commit: dependencies, secrets, build artifacts, logs, and editor clutter. This builder generates a thorough .gitignore for Node, npm, and JavaScript projects, with each section toggleable so you only ship the patterns you actually need.

How it works

Git reads .gitignore from the repository root and applies each line as a pattern: a name matches files and folders anywhere below, a trailing slash matches directories only, and a leading slash anchors to the root. This builder assembles grouped sections — dependencies (node_modules/), environment files (.env, .env.local), build output (dist/, build/, .next/), logs (*.log, npm-debug.log*), coverage (coverage/, .nyc_output/), editor folders (.vscode/, .idea/), and OS files (.DS_Store, Thumbs.db). Toggling a section simply includes or omits its block in the live output.

Section-by-section rationale

node_modules

Always ignored. node_modules/ can contain thousands of files and hundreds of megabytes — it is entirely reproducible from package.json and the lockfile with npm install. Committing it creates massive diffs, breaks cross-platform builds (some packages compile native binaries that are OS-specific), and makes git clone unnecessarily slow.

Environment files

.env and its variants (.env.local, .env.development.local, .env.production.local) commonly hold API keys, database URLs, and other secrets. Leaking these to a public repository can have serious consequences. The correct pattern is to commit a .env.example file with placeholder values and real values only in the local file that is gitignored.

Build output

dist/, build/, .next/ and similar directories are generated by your bundler or transpiler. They should never be committed to the source branch — they are rebuilt as part of your CI/CD pipeline or deploy step. Committing them causes large binary diffs and makes it impossible to know whether the deployed output actually matches the source.

Logs

Log files grow unboundedly and are specific to a particular run of the application. npm, Yarn, and various tools write *.log and *-debug.log files during installs and operations. These change on every install and add noise to the repository.

A typical output

# Dependencies
node_modules/

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

# Build output
dist/
build/
.next/
.turbo/

# Logs
*.log
npm-debug.log*

# Coverage
coverage/
.nyc_output/

# Editor
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

What you should always commit

  • package-lock.json or yarn.lock — pins exact dependency versions, essential for reproducible installs.
  • .env.example — a template showing which environment variables are required, with safe placeholder values.
  • Your TypeScript configuration (tsconfig.json) and ESLint configuration (.eslintrc, eslint.config.mjs) so all contributors use the same settings.

If you accidentally committed a file before adding it here, run git rm --cached <file> to stop tracking it while keeping it on disk, then commit the removal.

Patterns people often forget

.env.* variants. A plain .env entry only ignores .env exactly. Create-React-App, Next.js, and Vite also use .env.local, .env.development.local, .env.test.local, and .env.production.local. This builder adds .env.*.local to catch all variants automatically.

TypeScript declaration output. If you use tsc --declaration, the compiler writes *.d.ts and *.d.ts.map files alongside your source. These should not normally be committed for application code (they belong in a published package’s dist), but should be committed when you are publishing a library. This builder targets the dist/ folder, which covers the common application case.

.turbo/ folder. Turborepo caches build results in .turbo/. This is a local development artefact and should never be committed — but it was added to .gitignore templates relatively recently, so older repositories sometimes miss it.

Editor-specific files. .vscode/ and .idea/ contain editor-specific workspace settings. Whether to commit .vscode/ is contentious — it is useful to share extensions.json and recommended settings with a team, but personal keyboard shortcuts and window layout should not be committed. A common pattern is to add .vscode/* with an exception: !.vscode/extensions.json. This builder ignores the whole folder; adjust if your team shares editor config.

Combining with a global gitignore

Git supports a per-user global .gitignore file (set via git config --global core.excludesFile). Putting OS files like .DS_Store and Thumbs.db there means you never need to add them to every individual project’s .gitignore. This builder includes them in the per-project file by default for portability, but if you maintain a global ignore, you can safely uncheck the OS section here.