Como o mini se adapta ao seu projeto

O mini lê seu código e aumenta sua versão no lugar que combina com o seu projeto — entre linguagens, com alternativas sensatas.

Um mapa do projeto consciente da linguagem

O mini map constrói o mapa do projeto legível por máquina por arquivo, pela extensão — não a partir de uma única "linguagem do projeto". Um projeto pode misturar várias linguagens e cada arquivo reconhecido é mapeado. As extensões suportadas são:

.ts  .tsx  .php  .rs  .py  .go  .java  .cs  .kt  .kts  .swift  .rb

Arquivos com extensão não reconhecida, e diretórios de dependências ou de build como vendor/, target/, var/cache/ e node_modules/, são ignorados — assim o mapa fica focado no seu próprio código-fonte.

Onde a versão fica

Quando você fecha uma fase com --bump (e opcionalmente --push), o mini escreve a nova versão no arquivo que corresponde ao seu projeto. As fontes abaixo são tentadas em uma ordem fixa e ganha a primeira que já contém uma versão utilizável — só esse único arquivo é alterado.

Arquivo Quando o mini escreve a versão aqui
package.json Projetos JavaScript / TypeScript — o campo "version" no package.json.
Cargo.toml Projetos Rust — a versão na seção [package] do Cargo.toml.
pyproject.toml Projetos Python — a versão em [project] ou [tool.poetry] no pyproject.toml.
setup.py Projetos Python que usam setup.py — o argumento version="…".
composer.json Projetos PHP — só quando o composer.json já tem um campo "version" (o mini nunca adiciona um).
__version__ Projetos Python — uma linha __version__ = "…" em um local comum.
VERSION Qualquer projeto sem manifesto reconhecido — um arquivo VERSION simples com uma única linha x.y.z, criado com 0.1.0 quando ainda não existe.

A escrita é sempre uma substituição puramente textual do valor da versão, sem reformatar JSON ou TOML, então a mudança fica em uma única linha.

Exemplo: este próprio site é um projeto PHP/Symfony cujo composer.json não carrega campo de versão, então um aumento recai no arquivo alternativo VERSION.