For years, my VS Code environment kept getting more complex.
More extensions, more automation, more tools supposed to make development easier.
On paper, everything looked efficient. In practice, I spent more and more time fixing side effects.
Files reformatted themselves on save.
Indentation changed unexpectedly.
Two projects could look different simply because an extension behaved differently.
The tools were supposed to help.
Instead, they took control away.
The problem with automatic tooling
Automatic formatting is convenient — until it stops being predictable.
Some extensions rewrite code structure without real context.
Others apply different rules depending on language or local configuration.
Nothing is necessarily wrong, but the environment becomes unstable:
- invisible changes appear in commits
- code readability changes between projects
- and it becomes harder to understand what actually changed
At some point, I realized I was spending more time supervising my editor than writing code.
What I actually wanted
I didn’t want more automation.
I wanted fewer surprises.
A simple and predictable environment:
- no automatic changes without intent
- consistent rendering across projects
- formatting executed only when necessary
The goal was not to make the editor smarter,
but to make it more reliable.
Moving back to control instead of automation
I gradually removed everything that modified code automatically.
No format-on-save.
No extensions rewriting files in the background.
No hidden actions.
Instead, I adopted a simpler approach:
- cleanup actions are manual
- scripts run locally
- every modification is intentional
The code is never modified unless I explicitly decide to do it.
At first this feels less modern, but it has an immediate benefit:
everything becomes predictable again.
What changed in practice
The biggest change wasn’t technical — it was mental.
Less friction.
Fewer broken files caused by unexpected formatting.
A more stable and readable codebase over time.
My editor stopped making decisions for me.
It became a tool again.
All my projects started behaving the same way, regardless of system or context.
Local backups changed how I work
Another important change was how I handled file safety.
Instead of relying on extensions or external tools, I added a simple local backup system: every time a file is saved, a timestamped copy is created locally.
It’s not complex, but it removes unnecessary stress.
A file can be modified, broken, or even deleted by mistake — a previous version still exists.
This kind of local safety changes the way you work.
You experiment more freely because losing a stable version of your code becomes much less likely.
Conclusion
Over time, this setup became reusable because I wanted the same stability across projects.
But the real change wasn’t the configuration itself.
It was the mindset behind it:
tools should never modify code without intent.
Eventually, this environment evolved into a reusable setup at Palks Studio, but the main benefit remains the same — clarity, control, and predictability.
https://palks-studio.com/en/vscode-environment-pack
If you're interested in how it works under the hood:
Here’s a technical breakdown of the system architecture.
VS Code – Environment Pack
A configured working environment for Visual Studio Code.
This pack provides a clear and consistent framework for formatting, cleanup, and normalization
of common file types (.py, .html, .css, .js, .json, .txt),
using VS Code settings and locally executed Python scripts.
The goal is not blind automation,
but a controlled set of tools
that lets you keep full control over code structure, readability, and consistency,
regardless of the operating system.
Why this environment exists
Most editors automatically reformat code when saving files.
While convenient, this can introduce unexpected changes,
inconsistent formatting, or conflicts between extensions.
This pack takes the opposite approach:
- no automatic formatting
- no hidden actions
- manual tools executed only when needed
The goal is to keep code stable, readable and predictable,
while giving full control to the developer.
Pack Structure
vscode_environment_pack_v1.1/
│
├── .vscode/
│ ├── extensions.json → Local disabling of conflicting extensions (Prettier, RunOnSave)
│ ├── launch.json → Quick execution of the active Python script
│ ├── settings.json → Complete VS Code settings (indentation, LF, UTF-8, editor comfort)
│ ├── keybindings.json → Shortcuts: Alt + M (minimap), Alt + R (re-indentation)
│ └── tasks.json → VS Code tasks (manually executable):
│ - Python Formatting + Margin Cleanup
│ (autopep8 + clean.py, active file)
│ - Margin Cleanup (clean.py — global / active file / custom selection)
│ - Margin Detection (space.py — read-only analysis)
│ - CRLF → LF Conversion (convert.py — global / active file / custom selection)
│
├── clean.py → General margin and whitespace cleanup
├── convert.py → Line ending normalization (CRLF → LF)
├── space.py → Margin analysis (read-only)
├── backup.py → Timestamped backup of the file on save (Ctrl + S)
│ via the Auto-Backup task
│
├── LICENSE.md → Terms of use and legal framework
│
└── docs/
├── TECHNICAL_README.md → Technical documentation and internal structure
├── README_COMMERCIAL.md → Project overview and public presentation
├── INSTALL.md → Installation and usage guide
│
└── examples/
├── before.py → Dirty / unstructured example files
├── after.py → Clean, formatted versions generated by the pack
├── convert_lf.mp4 → CRLF files automatically converted to LF
├── indent_clean.mp4 → Broken indentation/margins fixed instantly
├── indent_python.mp4 → Badly indented Python file auto-corrected
├── backup.mp4 → Demonstrates automatic file backup on each save (Ctrl + S)
│ and how to restore a deleted file from the backup folder
└── space_clean.mp4 → Broken file analyzed and margins detected (read-only)
If you want to explore the technical implementation, you can find it here:
https://github.com/Palks-Studio/vs-code-environment-pack
Top comments (0)