██████╗ ███████╗██╗   ██╗ ██████╗██╗     ██╗
██╔══██╗██╔════╝██║   ██║██╔════╝██║     ██║
██║  ██║█████╗  ██║   ██║██║     ██║     ██║
██║  ██║██╔══╝  ╚██╗ ██╔╝██║     ██║     ██║
██████╔╝███████╗ ╚████╔╝ ╚██████╗███████╗██║
╚═════╝ ╚══════╝  ╚═══╝   ╚═════╝╚══════╝╚═╝

English | Português

Source code

A transparent, cross-platform developer environment bootstrapper written in Go.

Setting up a development environment after a fresh install is a repetitive and error-prone process. DevCLI solves this by acting as a single, opinionated entry point for installing language runtimes and build toolchains — with complete visibility into every decision it makes before executing anything.

Unlike shell scripts that run silently and mutate your system without warning, DevCLI builds a full installation plan first: tool, version, source URL, package manager, exact commands, and any PATH changes that will result. The user reviews this plan and confirms before a single command runs.

Transparency over convenience. The complete installation plan is always displayed before execution. Nothing happens implicitly.

Hybrid installation strategy. Native package managers are preferred for their reliability and integration with the host system. Official vendor sources — such as rustup or Adoptium Temurin — serve as fallbacks when the package manager route is insufficient or unavailable for a given platform.

No silent mutations. PATH changes are shown with the exact target file and the exact line that will be written. Duplicate entries are detected and never applied twice. Each change requires its own confirmation, separate from the installation step.

Dry-run as a first-class feature. Any installation can be fully previewed with --dry-run without touching the system.

When a target is outside the official matrix, the interface labels it explicitly as best effort rather than pretending full compatibility.

cmd/                  CLI entry points and command definitions
internal/catalog/     Declarative tool and version registry
internal/platform/    OS, shell, and package manager detection
internal/install/     Installation planner and executor
internal/ui/          Guided prompts and plan rendering
internal/i18n/        Localization (pt-BR and en)

The catalog layer expresses tools and versions as pure data structures — no logic, no side effects. The platform layer detects the operating system, active shell, and available package managers. The planner combines both to resolve the best installation method for the current environment and produces a Plan value before any mutation occurs. Execution is the final and isolated step.

This separation means adding a new tool requires only a new catalog entry. It also means the planner and executor can be tested independently of the actual system state.

Requires Go 1.22 or later. No external dependencies.

# Launch the interactive guided menu
go run .

# List all available tools
go run . list

# Install a specific tool and version
go run . install java 21

# Preview the full installation plan without executing anything
go run . install java 21 --dry-run

# Install without interactive confirmation prompts
go run . install rust stable --yes

# Override the interface language
DEVCLI_LANG=en go run . install node lts

When a tool and version are selected, DevCLI displays the full plan before asking for confirmation:

• Tool name and target version
• Detected operating system and package manager
• Chosen installation strategy (package_manager or vendor_download)
• Official source name and URL
• Exact commands that will be executed
• Required PATH changes: target profile file and the exact line to be written

Execution only begins after explicit confirmation.

The interface language is resolved automatically from the system locale, with the following priority:

1. DEVCLI_LANG environment variable
2. LC_ALL
3. LC_MESSAGES
4. LANG
5. Windows locale API (when applicable)

Locales starting with pt resolve to pt-BR. All others fall back to en.

• The tool catalog is local and static. There is no remote catalog, update check, or version resolution against live registries.
• Automatic PATH persistence is implemented for Unix-like user profiles (.bashrc, .zshrc, .profile, config.fish). Windows PATH configuration is not yet automated.
• Not every combination of tool, version, and platform has a direct vendor download path automated end-to-end.
• IDEs, browsers, and GUI utilities are outside the current scope.

• Skip already-installed tools by detecting the current version before planning
• Support for JetBrains IDEs, VS Code, Cursor, Chrome, and Firefox
• Checksum and signature verification for vendor downloads
• External catalog format (JSON or YAML) to allow community contribution without code changes

Contributions are welcome. The codebase is structured so that adding a new tool or version only requires a new entry in internal/catalog/ — no changes to the planner or executor are needed.

If you intend to contribute:

1. Fork the repository and create a branch from master.
2. Keep changes focused. One pull request per feature or fix.
3. If you are adding a new tool, include entries for all platforms the tool officially supports.
4. If your change affects user-facing output, update both the en and pt-BR strings in internal/i18n/i18n.go.
5. Open a pull request with a clear description of what was changed and why.

There are no external dependencies. The project builds with the standard Go toolchain.

This project is licensed under the MIT License.

Uma ferramenta de linha de comando para configurar ambientes de desenvolvimento com transparência total, escrita em Go.

Configurar um ambiente de desenvolvimento depois de uma formatação é um processo repetitivo e propenso a erros. O DevCLI resolve isso oferecendo um ponto de entrada único e opinativo para instalar runtimes de linguagens e toolchains de build — com visibilidade completa sobre cada decisão tomada antes de executar qualquer coisa.

Diferente de scripts que rodam silenciosamente e alteram o sistema sem aviso, o DevCLI constrói um plano de instalação completo primeiro: ferramenta, versão, URL da fonte oficial, gerenciador de pacotes, comandos exatos e quaisquer alterações de PATH que resultarão. O usuário revisa esse plano e confirma antes de um único comando ser executado.

Transparência antes de conveniência. O plano completo de instalação é sempre exibido antes da execução. Nada acontece de forma implícita.

Estratégia de instalação híbrida. Gerenciadores de pacotes nativos são preferidos pela sua confiabilidade e integração com o sistema. Fontes oficiais dos fornecedores — como rustup ou Adoptium Temurin — servem como fallback quando o gerenciador de pacotes não oferece uma rota adequada para a plataforma.

Sem mutações silenciosas. Alterações de PATH são exibidas com o arquivo de destino exato e a linha exata que será gravada. Entradas duplicadas são detectadas e nunca aplicadas duas vezes. Cada alteração exige uma confirmação separada, independente da etapa de instalação.

Dry-run como recurso de primeira classe. Qualquer instalação pode ser visualizada na íntegra com --dry-run sem tocar no sistema.

Quando o alvo está fora da matriz oficial, a interface o rotula explicitamente como best effort em vez de simular compatibilidade garantida.

cmd/                  Pontos de entrada da CLI e definição de comandos
internal/catalog/     Registro declarativo de ferramentas e versões
internal/platform/    Detecção de SO, shell e gerenciadores de pacotes
internal/install/     Planejador e executor de instalação
internal/ui/          Prompts guiados e exibição do plano
internal/i18n/        Localização (pt-BR e en)

A camada de catálogo expressa ferramentas e versões como estruturas de dados puras — sem lógica, sem efeitos colaterais. A camada de plataforma detecta o sistema operacional, o shell ativo e os gerenciadores de pacotes disponíveis. O planejador combina as duas para resolver o melhor método de instalação para o ambiente atual e produz um valor Plan antes de qualquer mutação ocorrer. A execução é a etapa final e isolada.

Essa separação significa que adicionar uma nova ferramenta requer apenas uma nova entrada no catálogo. Também significa que o planejador e o executor podem ser testados independentemente do estado real do sistema.

Requer Go 1.22 ou superior. Sem dependências externas.

# Abre o menu interativo guiado
go run .

# Lista todas as ferramentas disponíveis
go run . list

# Instala uma ferramenta e versão específicas
go run . install java 21

# Visualiza o plano completo sem executar nada
go run . install java 21 --dry-run

# Instala sem prompts de confirmação interativos
go run . install rust stable --yes

# Substitui o idioma da interface
DEVCLI_LANG=pt go run . install node lts

Quando uma ferramenta e versão são selecionadas, o DevCLI exibe o plano completo antes de pedir confirmação:

• Nome da ferramenta e versão alvo
• Sistema operacional e gerenciador de pacotes detectados
• Estratégia de instalação escolhida (package_manager ou vendor_download)
• Nome e URL da fonte oficial
• Comandos exatos que serão executados
• Alterações de PATH necessárias: arquivo de perfil alvo e a linha exata a ser gravada

A execução só começa após confirmação explícita.

O idioma da interface é resolvido automaticamente a partir do locale do sistema, com a seguinte prioridade:

1. Variável de ambiente DEVCLI_LANG
2. LC_ALL
3. LC_MESSAGES
4. LANG
5. API de locale do Windows (quando aplicável)

Locales iniciados com pt resolvem para pt-BR. Todos os outros usam en como fallback.

• O catálogo de ferramentas é local e estático. Não há catálogo remoto, verificação de atualizações ou resolução de versões contra registros ao vivo.
• A persistência automática de PATH está implementada para perfis de usuário Unix-like (.bashrc, .zshrc, .profile, config.fish). A configuração de PATH no Windows ainda não é automatizada.
• Nem toda combinação de ferramenta, versão e plataforma tem um caminho de download direto totalmente automatizado.
• IDEs, navegadores e utilitários gráficos estão fora do escopo atual.

• Detectar a versão já instalada para pular ferramentas desnecessárias
• Suporte para IDEs JetBrains, VS Code, Cursor, Chrome e Firefox
• Verificação de checksum e assinatura para downloads de fornecedores
• Formato de catálogo externo (JSON ou YAML) para contribuição da comunidade sem alterações no código

Contribuições são bem-vindas. O código está estruturado de forma que adicionar uma nova ferramenta ou versão requer apenas uma nova entrada em internal/catalog/ — nenhuma alteração no planejador ou executor é necessária.

Se você pretende contribuir:

1. Faça um fork do repositório e crie uma branch a partir de master.
2. Mantenha as alterações focadas. Um pull request por funcionalidade ou correção.
3. Se estiver adicionando uma nova ferramenta, inclua entradas para todas as plataformas que ela suporta oficialmente.
4. Se a sua alteração afetar a saída exibida ao usuário, atualize as strings de en e pt-BR em internal/i18n/i18n.go.
5. Abra um pull request com uma descrição clara do que foi alterado e por quê.

Não há dependências externas. O projeto compila com o toolchain padrão do Go.

Este projeto está licenciado sob a MIT License.