Wie sich mini an dein Projekt anpasst

Eine sprachbewusste Projektkarte

mini map baut die maschinenlesbare Projektkarte pro Datei, nach Erweiterung — nicht aus einer einzigen "Projektsprache". Ein Projekt kann mehrere Sprachen mischen, und jede erkannte Datei wird abgebildet. Die unterstützten Erweiterungen sind:

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

Dateien mit nicht erkannter Erweiterung sowie eingebundene oder Build-Verzeichnisse wie vendor/, target/, var/cache/ und node_modules/ werden übersprungen — so bleibt die Karte auf deinen eigenen Quellcode konzentriert.

Wo die Version liegt

Wenn du eine Phase mit --bump (und optional --push) abschließt, schreibt mini die neue Version in die Datei, die zu deinem Projekt passt. Die untenstehenden Quellen werden in fester Reihenfolge geprüft, und die erste, die bereits eine brauchbare Version enthält, gewinnt — nur diese eine Datei wird geändert.

Datei	Wann mini die Version hierhin schreibt
package.json	JavaScript-/TypeScript-Projekte — das Feld "version" in package.json.
Cargo.toml	Rust-Projekte — die Version unter dem Abschnitt [package] in Cargo.toml.
pyproject.toml	Python-Projekte — die Version unter [project] oder [tool.poetry] in pyproject.toml.
setup.py	Python-Projekte mit setup.py — das Argument version="…".
composer.json	PHP-Projekte — nur wenn composer.json bereits ein Feld "version" hat (mini fügt nie eines hinzu).
__version__	Python-Projekte — eine Zeile __version__ = "…" an einer üblichen Stelle.
VERSION	Jedes Projekt ohne erkanntes Manifest — eine einfache VERSION-Datei mit einer einzelnen Zeile x.y.z, die mit 0.1.0 angelegt wird, falls sie noch nicht existiert.

Das Schreiben ist immer eine reine textuelle Ersetzung des Versionswerts, ohne JSON- oder TOML-Neuformatierung, sodass die Änderung eine einzige Zeile bleibt.

Beispiel: Diese Website selbst ist ein PHP-/Symfony-Projekt, dessen composer.json kein Versionsfeld trägt, sodass eine Erhöhung auf die VERSION-Fallback-Datei zurückfällt.