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.