How mini adapts to your project

mini reads your code and bumps your version in the place that fits your project — across languages, with sensible fallbacks.

A language-aware project map

mini map builds the machine-readable project map per file, by extension — not from a single "project language". A project can mix several languages and every recognized file is mapped. The supported extensions are:

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

Files with an unrecognized extension, and vendored or build directories such as vendor/, target/, var/cache/ and node_modules/, are skipped — so the map stays focused on your own source.

Where the version lives

When you close a phase with --bump (and optionally --push), mini writes the new version into the file that matches your project. The sources below are tried in a fixed order and the first one that already holds a usable version wins — only that single file is changed.

File When mini writes the version here
package.json JavaScript / TypeScript projects — the "version" field in package.json.
Cargo.toml Rust projects — the version under the [package] section of Cargo.toml.
pyproject.toml Python projects — the version under [project] or [tool.poetry] in pyproject.toml.
setup.py Python projects using setup.py — the version="…" argument.
composer.json PHP projects — only when composer.json already has a "version" field (mini never adds one).
__version__ Python projects — a __version__ = "…" line in a common location.
VERSION Any project with no recognized manifest — a plain VERSION file holding a single x.y.z line, created with 0.1.0 when it does not exist yet.

The write is always a plain textual replacement of the version value, with no JSON or TOML reformatting, so the change stays a single line.

Example: this very site is a PHP/Symfony project whose composer.json carries no version field, so a bump falls through to the VERSION fallback file.