/ 01
Overview
A focused VS Code extension for turning a described layout into a file tree, previewing it, and materializing folders and stub files into the workspace. The goal is a boring, predictable utility: strict validation, no silent overwrites, and a workflow that matches how people already structure repos.
The extension works from a strict, parseable tree format. Parsing rejects malformed input instead of guessing, and the file writer is conflict-aware — existing work is never overwritten by default. Everything the extension generates goes to an unsaved editor tab first; nothing touches disk until you explicitly apply it.
Under the hood it's a small, real service-oriented codebase, not a single-file script: a lightweight dependency-injection container wires together a tree-builder service, a file-system service, an exclusion service (glob-based ignore patterns), and four output formatters (ASCII, Markdown, JSON, SVG) behind a common interface. An LRU cache backs the file-system scan so repeated previews of the same folder don't re-walk the disk. 243 tests currently pass across the suite.
/ Scope
- VS Code extension API integration
- Strict tree schema & parser
- Preview webview before filesystem write
- Conflict-aware file system writer
- Marketplace release & version management
/ 02
Highlights
01
Preview-first file tree generation — see before you write
02
Conflict-aware writes — existing files never silently overwritten
03
36,000+ installs, 5.0 rating on VS Code Marketplace
04
Strict schema validation with clear, actionable error messages
/ Tracks
- Product
- Open source
/ 03
Media
External preview
Open linkmarketplace.visualstudio.com
FileTree Pro on VS Code Marketplace — 36k+ installs, 5.0 rating
/ 04
The Problem
New projects repeat the same folder patterns — components, hooks, tests — and it's easy to miss a convention or accidentally clobber an existing file. I wanted a small tool that lets you design the tree first, preview it, then apply it carefully.
/ 05
Approach
The extension works from a strict, parseable tree format: describe the shape you want, see it in a preview webview, and only then write to disk. The file writer skips existing files by default, with an explicit opt-in rename when the user wants to overwrite.
/ 06
Key Decisions
- 01
Reject over guess
Output must match a known tree structure. When it doesn't, the extension fails with a clear error instead of guessing at the user's intent and generating something half-right. A wrong guess that half-writes a directory is worse than no output at all. - 02
Preview before write
A webview renders the tree before any filesystem change happens. Eliminates 'oops I just overwrote my components/' moments in real repos. - 03
Small command surface, on purpose
The whole workflow is generate, preview, apply — so the command palette only needs to expose those steps, not a menu of configuration options standing in for features that don't exist yet. - 04
Service container instead of one big extension.ts
A small dependency-injection container wires together the tree builder, file-system service, exclusion service, and formatters, instead of instantiating everything inline in the extension's activation function. Makes each piece independently testable — the 243-test suite mocks the VS Code API at the boundary and tests real business logic underneath, not stubs. - 05
Formatter strategy pattern for output
Four output formats (ASCII, Markdown, JSON, SVG) share one interface behind a factory. Adding a fifth format means writing one new class, not touching the four existing ones. - 06
Cache the scan, not the tree
The preview-then-apply workflow means the same folder often gets scanned more than once in a session — preview, tweak, preview again. An LRU cache sits behind the file-system scan so repeated previews of the same folder don't re-walk the disk each time. - 07
Exclusions as their own service, not inline filtering
Glob-based ignore patterns live in a dedicated exclusion service, wired through the same DI container as the tree builder and file-system service — not scattered as inline filtering checks. One place to reason about what gets excluded and why.
/ 07
Challenges & How I Solved Them
01
Robust parsing of noisy input
/ Problem
Early builds had to tolerate noisy input — markdown code fences, indentation drift, mixed spacing — while still producing a single validated tree structure.
/ Solution
Strip and normalize first, then run a strict structure check. Bad input fails loudly with a specific error. Good input always produces the same deterministic result.
02
Preserving existing workspace files
/ Problem
Re-running the flow after initial scaffold could silently overwrite files the user had already edited — a trust-destroying experience.
/ Solution
Default behavior skips any file that already exists. Users who want to replace can opt-in explicitly with a rename suffix. Existing work is safe by default.
/ 08
Outcomes
- 36,000+ installs on the VS Code Marketplace
- 5.0 average rating across active reviews
- Steady organic adoption — no promotion, just the listing
- 243 passing tests across the suite, covering the tree builder, formatters, security validation, and caching
- Zero reported 'silent overwrite' incidents since conflict-awareness shipped
/ 09
What I Learned
- 01
Utilities that respect the user's existing work build more trust than utilities with more features.
- 02
Strict validation is a feature, not a limitation, when anything can write to the workspace.
- 03
Marketplace success tracks directly to clarity in the listing — title, screenshots, and a one-line description of what it does.
/ 10
Tech Stack
TypeScriptVS Code APIWebview UI
/ 11
Next Steps
- Reusable project-shape presets (save and recall a tree layout)
- Stack-aware defaults (e.g. Next.js vs NestJS layout hints)