Comment mini s'adapte à ton projet

Une carte de projet consciente du langage

mini map construit la carte de projet lisible par la machine par fichier, selon l'extension — pas à partir d'un unique « langage du projet ». Un projet peut mêler plusieurs langages et chaque fichier reconnu est cartographié. Les extensions prises en charge sont :

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

Les fichiers à l'extension non reconnue, ainsi que les répertoires de dépendances ou de build comme vendor/, target/, var/cache/ et node_modules/, sont ignorés — la carte reste donc centrée sur ton propre code source.

Où vit la version

Quand tu fermes une phase avec --bump (et éventuellement --push), mini écrit la nouvelle version dans le fichier qui correspond à ton projet. Les sources ci-dessous sont essayées dans un ordre fixe et la première qui contient déjà une version utilisable l'emporte — seul ce fichier unique est modifié.

Fichier	Quand mini écrit la version ici
package.json	Projets JavaScript / TypeScript — le champ « version » dans package.json.
Cargo.toml	Projets Rust — la version sous la section [package] de Cargo.toml.
pyproject.toml	Projets Python — la version sous [project] ou [tool.poetry] dans pyproject.toml.
setup.py	Projets Python utilisant setup.py — l'argument version="…".
composer.json	Projets PHP — seulement quand composer.json a déjà un champ « version » (mini n'en ajoute jamais).
__version__	Projets Python — une ligne __version__ = "…" à un emplacement courant.
VERSION	Tout projet sans manifeste reconnu — un simple fichier VERSION contenant une seule ligne x.y.z, créé avec 0.1.0 quand il n'existe pas encore.

L'écriture est toujours un remplacement purement textuel de la valeur de version, sans reformatage JSON ni TOML, donc le changement reste une seule ligne.

Exemple : ce site même est un projet PHP/Symfony dont le composer.json ne porte pas de champ de version, donc une montée retombe sur le fichier de repli VERSION.