Why I Built It
For years, I kept adding new tools to my development environment because every extension, formatter, or utility promised to make development faster. At first it worked, but over time my workflow became harder to understand. Files were modified automatically, formatting changed from one project to another, and some actions happened in the background without me even noticing.
The problem wasn't Visual Studio Code, and it wasn't the extensions themselves. The real problem was that I had gradually stopped controlling my own development environment.
Instead of installing even more tools, I started removing them. I replaced hidden automation with explicit actions and built a lightweight local environment around a simple principle:
Nothing should modify my code unless I decide it.
Over time, this approach evolved into what is now my VS Code Environment Pack. Rather than trying to automate everything, it provides a collection of local tools that help me create projects, maintain codebases, generate documentation, keep timestamped backups, and automate repetitive tasks while keeping every action predictable and under my control.
Links
Every Project Starts the Same Way
One of the first repetitive tasks in any project has nothing to do with writing code.
Creating folders.
Creating empty files.
Reproducing the same directory structure again and again.
It doesn't take long, but after dozens of projects it becomes unnecessary work.
Instead of creating everything manually, I describe the project structure once in a simple structure.txt file. Running a single task generates the complete hierarchy, including every folder and file exactly where it belongs.
my_project
README.md
app
app.py
static
css
style.css
The goal isn't to generate code.
It's to start every project from a clean, consistent structure, so I can focus on solving the actual problem instead of rebuilding the same foundation every time.
Documentation Should Never Be Manual
Understanding a project often starts with a simple question:
How is it organized?
When a codebase grows, answering that question manually becomes surprisingly time-consuming. Taking screenshots, writing folder structures, or listing files by hand quickly becomes outdated.
That's why I built tree.py.
With a single task, it scans the entire project and generates a PROJECT_TREE.txt file representing the complete directory structure.
my_project/
├── app
│ ├── app.py
│ └── controllers
├── static
│ ├── css
│ └── js
├── README.md
└── requirements.txt
I use it to document projects, share their architecture, review existing codebases, and quickly understand how a project is organized.
Like every other tool in this environment, it performs one task, does it locally, and produces a result that is easy to read, reuse, and version.
Every Change Is Intentional
One of the principles behind this environment is that no script should modify more files than necessary.
That's why most maintenance tools can run in three different modes.
Sometimes I want to clean an entire project before committing it.
Sometimes I only want to work on the file I'm editing.
And sometimes I need to target a small selection of files without touching anything else.
Instead of forcing a single workflow, the environment adapts to the situation.
The same approach applies to cleaning whitespace, converting line endings, and other maintenance tasks. Every operation can be executed on the whole project, the active file, or a custom selection.
Nothing runs automatically in the background.
Nothing changes unless I ask for it.
That level of control makes maintenance safer, especially on large projects where a single unintended modification can affect hundreds of files.
Every Save Creates a Safety Net
Making changes is part of development.
Deleting the wrong block, trying a different implementation, or restructuring a file happens every day. Most of the time, version control is enough. Sometimes, it isn't.
I wanted something much simpler.
Every time I save a file, a timestamped copy is created automatically inside a local backup directory. Nothing is uploaded, nothing is synchronized, and nothing depends on an external extension or service.
If I realize a mistake a few minutes later, I don't need to search through Git commits or recover a deleted file. The previous version is already there.
More importantly, this changes the way I work.
I can experiment more freely because I know every saved version still exists. Refactoring becomes less stressful, trying a new approach becomes easier, and recovering from a mistake takes seconds instead of minutes.
The backup system isn't just about protecting files.
It's about giving me the confidence to change them.
Small Tools, One Responsibility
One design decision guided the entire project: every tool should solve one problem, and solve it well.
Instead of building one large application responsible for formatting, backups, project generation, documentation, and file maintenance, I chose to keep every feature independent.
create.py creates projects.
tree.py documents them.
clean.py removes unnecessary whitespace.
space.py reports formatting issues without modifying anything.
convert.py normalizes line endings.
backup.py keeps timestamped copies of every saved file.
Each tool can evolve independently, remain easy to understand, and be reused in other projects without bringing along features that aren't needed.
The result isn't just easier to maintain.
It's easier to trust.
When a tool has one responsibility, you always know why you're running it and exactly what it will do.
Conclusion
This project didn't start as a VS Code pack.
It started with a simple question:
How can I build an environment that stays predictable, even as my projects become larger and more complex?
Over time, the answer became a collection of small local tools designed to solve everyday problems without introducing unnecessary complexity.
Creating projects.
Documenting architectures.
Maintaining codebases.
Keeping local backups.
Cleaning and formatting files.
Every tool has a single responsibility, every action is explicit, and every modification remains under my control.
Today, this environment is part of every project I build.
Not because it automates everything, but because it automates the right things while letting me decide when and how they happen.
For me, that's what a good development environment should do.
It shouldn't write code for the developer.
It should help the developer write better code with confidence.
Go Further
Explore more technical articles
Read more technical notes
Top comments (0)