# antfu/vscode-file-nesting-config: A Shared File Nesting Snippet for VS Code

> The repository is a generated settings.json snippet plus an extension that keeps it current. It is opinionated by design, and the trade-off is that your Explorer stops matching the folder on disk.

**antfu/vscode-file-nesting-config** — Config of File Nesting for VS Code

- Repository: https://github.com/antfu/vscode-file-nesting-config
- Stars: 3,667 · Forks: 202
- Language: JavaScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/antfu-vscode-file-nesting-config

## The problem: config files outnumber source files in the Explorer

A modern project root holds one source file and a dozen satellites. A Next.js app has next.config.ts, tsconfig.json, eslint.config.js, postcss.config.js and a lockfile sitting next to the code. A Rust crate has Cargo.toml, Cargo.lock, rust-toolchain.toml and a .clippy.toml. None of those files need to be opened most days, but they all take a row in the sidebar.

VS Code added Explorer file nesting in v1.67. The feature lets you declare that certain files are shown as children of another file rather than as siblings. The setting is explorer.fileNesting.patterns, a map from a parent file name to a comma-separated list of glob patterns. antfu/vscode-file-nesting-config is a ready-made value for that map, covering roughly a hundred parent files across the ecosystems the author works in. It is aimed at developers who keep several stacks in one editor profile and do not want to hand-write nesting rules per repository.

The README is explicit that the result is "very opinionated". That is the honest framing. This is not a neutral default; it is one developer's idea of which files belong under which parent, published as a snippet you copy or install.

## How the pattern map actually works

The core of the repository is a single JSON object. Each key is a file that stays visible in the tree. Each value is a comma-separated list of globs that get folded underneath it. For example, the README's snippet maps .clang-tidy to ".clang-format, .clangd, compile_commands.json", so those three files disappear into a collapsed .clang-tidy row.

Patterns support capture groups. The README includes "I*.cs": "$(capture).cs", which nests a C# interface file's implementation beside it. The same mechanism appears in the Svelte rules, where +layout.svelte captures +layout.ts, +layout.server.ts and similar files. This is the part that makes the config more than a static list: the glob is evaluated against the parent's own name.

Two global flags sit alongside the patterns. explorer.fileNesting.enabled turns the feature on, and explorer.fileNesting.expand set to false keeps nested groups collapsed by default, which is the point of the exercise. Both keys appear in the README's snippet with those values.

The repository does not ship the patterns by hand. update.mjs at the top level is a Node script, run through the update npm script, and the package.json shows pnpm@11.9.0 as the package manager with a workspace containing extension/. The README's snippet carries a comment line with the generation timestamp, "updated 2026-06-24 04:19", which is how a pasted copy tells you how stale it is.

## Installing it: extension or a paste into settings.json

There are two routes, and the README presents both. The extension route is the one the project now recommends: "We now have a new VS Code extension to handle the updates automatically for you," with a link to the extension directory's own README for instructions. That README is the place to look for the marketplace identifier and the update behaviour, since the top-level README does not restate them.

The manual route is a copy and paste. Open the command palette in VS Code, run Preferences: Open User Settings (JSON), and add the keys from the snippet. The README gives the full block; the shape of the first few lines is this:

```jsonc
  "explorer.fileNesting.enabled": true,
  "explorer.fileNesting.expand": false,
  "explorer.fileNesting.patterns": {
    ".env": "*.env, .env.*, .envrc, env.d.ts",
    ".gitignore": ".gitattributes, .gitmodules, .gitmessage, .lfsconfig, .mailmap, .git-blame*"
  }
```

If you already have explorer.fileNesting.patterns in your settings, do not paste a second copy. JSON objects with a duplicate key keep the last one, so the snippet silently replaces your rules. Merge the entries instead, or start from the snippet and add back the patterns you care about.

VS Code must be at least v1.67, which the README states as a requirement. On an older build the keys are accepted but nothing nests.

If you want to regenerate the snippet yourself rather than trust the published copy, the repository exposes the script:

```bash
pnpm install
pnpm run update
```

The update script writes the generated config; the README does not document what files it rewrites or whether it can be run offline, so treat the output as something to inspect before committing.

## What you give up when the Explorer stops matching the disk

Nesting is a display transform. The files are still where they were, but the sidebar no longer shows the directory as ls would. Anyone who navigates by muscle memory, or who reads paths off the screen while typing a command, will occasionally be wrong about where something lives.

There is a second cost: the rules are broad. The .gitignore entry swallows .gitattributes, .gitmodules, .gitmessage, .lfsconfig and .mailmap. If you edit .mailmap regularly, it now costs an extra click every time. The same applies to the large config-file lists attached to app.config.*, astro.config.*, gatsby-config.* and artisan, which pull in dozens of tool configs at once. That breadth is deliberate; it is also the reason the README calls the config opinionated rather than sensible defaults.

Third, the top-level README does not document how to undo the extension's changes, or whether the extension writes to your user settings or only reads them. If you install the extension and later want a different ruleset, verify that path in the extension README before you commit to it. The manual paste has no such ambiguity: delete the keys and you are back to a flat tree.

Finally, this is the wrong tool if your project's file layout is itself the information. In a repo where two files with similar names must be visually distinguishable at a glance, collapsing one under the other hides exactly the distinction you need.

## Compared with writing your own patterns

The alternative is not a different product. It is the explorer.fileNesting.patterns key you can fill in yourself, which is what the feature ships with and what this repository pre-populates. The difference is coverage versus control.

A hand-written config is usually five to fifteen lines: nest the lockfile under the manifest, nest the test config under the app config, stop. It takes ten minutes, it never surprises you, and it never needs updating because nothing external changes it. The cost is that you redo the work in every ecosystem you touch, and you will not think of .clang-tidy or build-wrapper.log until the day they annoy you.

This repository's answer is breadth plus a generator. update.mjs exists so the patterns can be maintained in one place and emitted into the README, and the extension exists so users do not have to re-paste. That is a real advantage for someone who moves between Node, Rust, Go, Python, Java, .NET, Nix and Docker in the same week. It is a disadvantage for someone whose stack is one framework and who now inherits rules for twenty others.

There is a middle path the repository supports: paste the snippet once, then delete the entries for ecosystems you never open. The generated timestamp comment tells you which version you started from.

## Maintenance, licence and what the repository does not tell you

The last push to the default branch was on 2026-06-24, and the most recent release, v2.0.2, is dated the same day. The release before it, v2.0.1, is from 2025-08-25, so the cadence is irregular: long quiet periods, then a bump. The repository is not archived. The maintenance signal that matters here is different from a library's, though. A stale nesting config does not break anything; it just fails to cover a tool that was released after it. The timestamp comment in the snippet is the mechanism for noticing that.

The licence is MIT, declared in package.json and present as a LICENSE file at the top level. For a settings snippet, the practical implication is that you can copy the JSON into your own dotfiles or a company settings profile without a separate agreement. MIT does not require you to preserve attribution in a settings file, though the generated snippet includes a comment line with the repository URL, which is a reasonable thing to leave in place. This is a description of the licence text, not legal advice; check with whoever handles licensing where you work if you are redistributing it inside a product.

The upgrade cost is low by construction. There is no runtime, no dependency you install into your project, and no build step for consumers. Upgrading means re-pasting a JSON block or letting the extension do it. The one thing to watch is that a regenerated snippet can add or remove patterns between versions, so a diff before pasting will tell you what changed in your tree.

## Conclusion

Adopt it if you work across JavaScript, Rust, Go, Python, Docker and Nix projects and want one nesting ruleset instead of writing your own. Skip it if your team relies on the Explorer showing a literal directory listing, or if you maintain your own patterns and do not want a second source of truth. Before installing, check that your VS Code is at least v1.67, read the extension's own README for its update behaviour, and diff the pasted snippet against your existing explorer.fileNesting.patterns so you know which rules you are giving up.

## FAQ

### What is file nesting in VS Code?

It is an Explorer feature, added in VS Code v1.67, that shows certain files as children of another file instead of as siblings. antfu/vscode-file-nesting-config supplies a ready-made set of patterns for that feature.

### Should settings.json be committed to a repository?

The README does not cover repository-level settings files. What it does show is a user-level snippet pasted into settings.json, with no instruction to share it, which implies the config is treated as personal rather than shared.

### How do I install antfu/vscode-file-nesting-config?

Either install the VS Code extension, whose README the project points to for instructions, or copy the JSON snippet from the top-level README into your settings.json. The extension route is described as handling updates automatically.

### Which VS Code version does antfu/vscode-file-nesting-config need?

The README states that VS Code v1.67 is required, which is the release that introduced Explorer file nesting.

### Can I edit the nesting patterns in antfu/vscode-file-nesting-config?

Yes. The snippet is plain JSON pasted into settings.json, so you can delete entries for ecosystems you do not use. If you paste it over an existing explorer.fileNesting.patterns key, the pasted object replaces your rules, so merge instead.

## Sources

- [antfu/vscode-file-nesting-config on GitHub](https://github.com/antfu/vscode-file-nesting-config)
- [Issues](https://github.com/antfu/vscode-file-nesting-config/issues)
- [License: MIT](https://github.com/antfu/vscode-file-nesting-config/blob/main/LICENSE)
- [README](https://github.com/antfu/vscode-file-nesting-config/blob/main/README.md)
- [Releases](https://github.com/antfu/vscode-file-nesting-config/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/antfu-vscode-file-nesting-config