IGNOREIT: configure your ignore list once, and it's applied in every repo

Every project ends up with files that should never be committed: .env files and private keys, but also node_modules, build output, test coverage, Terraform state, editor and OS files. Each new repo needs the same .gitignore lines again, and it only takes one forgotten line and one git add . for them to land in git.

For build output that's just noise in your history. For secrets it's worse: deleting the file afterwards doesn't help, because it stays in git history, every clone already has it, and bots scan public repositories for keys within minutes. The only real fix then is to rotate every secret in it.

IGNOREIT removes that step. You configure your list of files and folders once, in VS Code. From then on, in every project you open, any file or folder on that list is added to .gitignore as soon as it shows up, before you get the chance to commit it.

It's free, open source, and has been on the VS Code Marketplace since 2020, with 1,800+ installs.

In short: install it, then list what you never want in git, for example "ignoreit.array": [".env", "*.pem", "node_modules", "coverage"]. From then on, those files and folders are always ignored, in every repo you open.

What it does

• Applies your list everywhere. One list in your VS Code settings covers every project. When a file or folder from it exists in the project, it's added to .gitignore. No .gitignore yet? One is created.
• Keeps watching. Files that appear later, like a coverage folder after your first test run or a key you download, are added as soon as they show up.
• Leaves your own entries alone. New lines are appended at the end. Anything you wrote by hand stays where it is, and an entry that's already covered isn't added again.
• Understands wildcards. *.pem covers server.pem and client.pem. Dotfiles like .env match too.
• Keeps .env.example in sync (optional). It copies the variable names from .env into .env.example, without the values, so teammates know what to set.
• Tells you what it did. A notification such as .env, *.pem added to .gitignore appears each time it changes the file.

Install

In VS Code, open the Extensions view (Cmd/Ctrl + Shift + X), search for ignoreit, and click Install. Or from a terminal:

code --install-extension marcdomain.ignoreit

It needs nothing else. It works in any folder that is a git repository, meaning the folder you open has a .git folder at its root.

Choose what to ignore

Open Settings (Cmd/Ctrl + ,) and search for ignoreit:

The two settings: the list of files and folders, and the .env.example option

Click Add Item to add an entry. Or open settings.json (Command Palette → Preferences: Open User Settings (JSON)) and edit the list directly:

{
  "ignoreit.array": [".env", "*.pem", "*.key", "node_modules", "coverage"]
}

The default is [".env", "*.pem"].

• Put it in your User settings to protect every project you open.
• Put it in a project's .vscode/settings.json to use a different list for that project.

After changing the list, run Developer: Reload Window so the extension picks it up.

Starter lists

A few lists worth copying. Add only what you never want committed:

Folders are written without a trailing slash: node_modules, not node_modules/.

When it runs

• Automatically, whenever files in the workspace change, for example when you save. Changes to .gitignore and .env.example themselves don't trigger it, so it never loops.
• On demand, with the command ignoreit: auto ignore files and folders from the Command Palette, or the shortcut Cmd + Shift + I (macOS) / Ctrl + Shift + I (Windows, Linux).

A walk-through

Here's a new project with a .git folder and no .gitignore yet:

my-api/
├── .git/
├── .env
├── server.pem
├── node_modules/
├── package.json
└── src/

With this list:

{ "ignoreit.array": [".env", "*.pem", "node_modules", "coverage"] }

IGNOREIT shows .env, *.pem, node_modules added to .gitignore and creates:

.env
*.pem
node_modules

coverage isn't added yet, because there's no coverage folder. Run your tests, and as soon as coverage/ appears you'll see coverage added to .gitignore:

.env
*.pem
node_modules
coverage

Run it again with nothing new, and nothing happens. It never adds the same entry twice.

With an existing .gitignore

Your file is kept as it is, and only what's missing is appended. If the project already has:

# mine
dist/
.env*

and your list is [".env", "*.pem"] with a .env and a server.pem in the project, only *.pem is added. .env is skipped because .env* already covers it.

Keep .env.example in sync

.env.example is the file you do commit. It lists the variables the app needs, without their values, so a new teammate can copy it to .env and fill it in. Keeping it up to date by hand is easy to forget. Turn on the second setting:

{
  "ignoreit.array": [".env", "*.pem"],
  "ignoreit.updateEnvExample": true
}

It only runs when .env is in ignoreit.array and the project has a .env file.

When there's no .env.example, it creates one from .env with every value removed. Comments and blank lines are kept:

# .env
# Database
DATABASE_URL=postgres://admin:s3cret@localhost:5432/app
REDIS_URL=redis://localhost:6379

STRIPE_KEY=sk_live_51H…

# .env.example (generated)
# Database
DATABASE_URL=
REDIS_URL=

STRIPE_KEY=

When .env.example already exists, it only appends variables that are new. Your comments, ordering and example values are kept:

# .env.example, before
# documented
A=example-a

Add B and C to .env, save, and it becomes:

# .env.example, after
# documented
A=example-a
B=
C=

It never removes a variable from .env.example, so if you delete one from .env, remove it from the example yourself.

Good to know

• It looks at the top level of the project. A server.pem in the project root is detected; one inside certs/ isn't. The *.pem line it writes still ignores .pem files at any depth, because that's how .gitignore patterns work.
• Write folders without a trailing slash in the list (node_modules). If your .gitignore already says node_modules/, IGNOREIT may add a plain node_modules line too. Both mean the same thing to git, so it's harmless.
• Be careful with .env*. It catches .env.local and .env.production, but in .gitignore it also hides .env.example, which you want to commit. List the exact files instead (.env, .env.local), or add !.env.example to your .gitignore after the .env* line.
• Multi-root workspaces: it works on the first folder of the workspace.
• It doesn't scan file contents. It matches names. Hard-coded secrets in source files need a secret scanner, such as GitHub's push protection.

Already committed a secret?

.gitignore only stops untracked files from being added. If a file is already in git, ignoring it does nothing. To fix it:

1. Rotate the secret first. Assume it's compromised: change the password, revoke the key.

2. Stop tracking the file, keeping it on disk:

   git rm --cached .env
   git commit -m "Stop tracking .env"

3. If the repository is shared or public, the file is still in history. Remove it with a tool like git filter-repo, then force-push and ask everyone to re-clone. This is why rotating comes first.

Settings

Version history

Links

• VS Code Marketplace
• Source on GitHub: issues and pull requests welcome
• If it saves you from a leaked key, you can buy me a coffee ☕️