vasily-sviridov/dotfiles

This repository is a personal dotfiles system centered on a single install pipeline: ./install bootstraps the machine, and Dotbot applies the selected setup steps to place config files, run installers, and wire everything together.

The main architectural boundary is between orchestration and payload. Orchestration lives in the install script, Dotbot, and the step files under steps/. The payload is the actual configuration content in config/, shell/, nvim/, and dependencies/.

dotbot/ is vendored in the repo and used as the configuration engine. The README notes that installation is step-based: the user can enable or disable pieces by commenting out run_dotbot 'steps/...' entries. That means the setup is intentionally modular rather than a monolithic “install everything” flow.

steps/terminal.yaml is the visible Dotbot step definition in the tree. It is likely the top-level wiring for terminal-related symlinks or commands, while the rest of the repo provides the files those steps install or source.

The config/ directory contains host-level configuration artifacts that are typically linked into standard locations: editor formatting, Git behavior, shell startup, and plugin manager settings. The presence of editorconfig, gitattributes, gitconfig, zplugrc, and zshrc suggests this repo configures the developer environment across editor, VCS, and shell layers.

The shell/ directory is a shell-profile composition layer. Files like .exports, .aliases, .external, .std, and .wsl imply the shell environment is split into reusable fragments rather than one large profile. This allows the Zsh startup config to source common definitions while keeping platform-specific behavior isolated.

The dependencies/ subtree is a separate bootstrap subsystem for software installation. dependencies/install is the entry point, and dependencies/lib/*.sh breaks the logic into shared helpers plus OS/runtime-specific installers for macOS, Ubuntu, Go, Rust, NVM, and uv. That makes dependency provisioning a distinct phase from dotfile linking.

The nvim/ directory is a complete Neovim configuration boundary. It has its own init.lua, plugin lock files, and Lua modules under lua/config and lua/plugins. This is not just a single plugin file; it is a structured editor stack with options, keymaps, autocommands, and plugin registration separated into layers.

Neovim plugin management appears to be based on LazyVim/Lazy.nvim conventions. nvim/lazy-lock.json and nvim/lazyvim.json indicate pinned plugin state and a preset/configuration baseline. The plugin modules (blink.lua, gitsigns.lua, snacks.lua, theme.lua, cyrillic.lua) define the editor’s functional pieces and UI behavior.

The repo also contains automation for keeping editor dependencies current. .github/workflows/update-lazy-plugins.yml likely updates the Neovim plugin lockfile, and Dependabot is configured to monitor dependencies. That means the repo has an explicit maintenance path for both system packages and editor plugins.

Overall, the architecture is: Dotbot-driven bootstrap at the center, OS/runtime installers for dependencies, shell and Git/editor configs as installable artifacts, and Neovim as a self-contained subplatform with its own dependency tracking and update automation.