---
title: "La CLI de Nibiru"
description: "Chaque indicateur, chaque sous-commande du binaire `./nibiru`."
---

Le binaire `./nibiru` est un outil en ligne de commande compilé qui est inclus dans chaque projet Nibiru. Il génère des modules, des contrôleurs et des plugins, exécute les migrations, gère le cache et (avec le module CMS) crée et supprime des pages.
```
  _   _ _ _     _              ______                                          _
 | \ | (_) |   (_)            |  ____|                                        | |
 |  \| |_| |__  _ _ __ _   _  | |__ _ __ __ _ _ __ ___   _____      _____  _ _| | __
 | . ` | | '_ \| | '__| | | | |  __| '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ /
 | |\  | | |_) | | |  | |_| | | |  | | | (_| | | | | | |  __/\ V  V / (_) | |  |   <
 |_| \_|_|_.__/|_|_|   \__,_| |_|  |_|  \__,_|_| |_| |_|\___| \_/\_/ \___/|_|  |_|\_\
```
## Tous les indicateurs

| Drapeau | Ce qu'il fait |
|---|---|
| `-m {nom}` | Générer un nouveau module nommé `{nom}`. Ajouter `-g` pour connecter les accroches de journalisation Graylog. |
| `-c {nom}` | Générer un nouveau contrôleur `{nom}` ainsi que son modèle. |
| `-p {nom} -m {module}` | Générer un nouveau plugin `{nom}` à l'intérieur de `{module}`. Ajouter `-g` pour Graylog. |
| `-cache-clear` | Effacer `application/view/templates_c/` et `application/view/cache/`. |
| `-s` | Initialiser les dossiers du framework et corriger les permissions. Exécuter une fois après l'installation. |
| `-mi {env}` | Exécuter les migrations depuis `application/settings/config/database/` contre `local`, `staging` ou `production`. |
| `-mi-reset {env}` | Supprimer la table d'audit des migrations pour `{env}`. **Destructif.** |
| `-mi-reset-file {fichier} {env}` | Oublier qu'un seul fichier de migration a été exécuté pour `{env}`. |
| `-ws {URL} -wp {PORT}` | Se connecter à un WebSocket à `{URL}:{PORT}` (REPL interactif). |
| `-new-cms-page {nom}` | (Module CMS uniquement) Créer une nouvelle page CMS liée à un modèle existant. |
| `-delete-cms-page {nom}` | (Module CMS uniquement) Supprimer une page CMS. |
| `-h` | Afficher le texte d'aide. |
| `-v` / `-version` | Imprimer la version du binaire et la version du framework. |

## Commandes quotidiennes que vous utiliserez effectivement
```bash
# create a controller + view
./nibiru -c products

# create a module with Graylog hooks
./nibiru -m billing -g

# create a plugin inside that module
./nibiru -p invoices -m billing

# run migrations
./nibiru -mi local

# clear the Smarty cache after a deploy
./nibiru -cache-clear

# show framework version
./nibiru -v
```
## Environnements

La plupart des commandes respectent `APPLICATION_ENV` :
```bash
APPLICATION_ENV=production ./nibiru -mi production
APPLICATION_ENV=staging    ./nibiru -mi staging
```
L'argument `{env}` suivant `-mi` sélectionne la cible des migrations ; les deux doivent correspondre.

## Sur quoi est basé le CLI

L'exécutable binaire est une compilation de C++ qui lie contre les bibliothèques clientes MySQL, PostgreSQL (libpq) et ODBC. La compilation conditionnelle signifie qu'un binaire construit sans libpq fonctionne toujours pour des déploiements exclusivement avec MySQL — une dégradation gracieuse plutôt qu'une dépendance dure.

Vous trouverez le binaire à la racine du projet à côté de `index.php`. Il est exécutable dès l'installation (`chmod +x nibiru` si nécessaire).

## Intégration continue

Une étape simple d'Actions GitHub :
```yaml
- name: Run migrations
  run: |
    APPLICATION_ENV=production ./nibiru -mi production
  env:
    DB_HOST: ${{ secrets.DB_HOST }}
    DB_USER: ${{ secrets.DB_USER }}
    DB_PASS: ${{ secrets.DB_PASS }}
```
Le CLI se termine avec un code différent de zéro si toute migration échoue, donc le CI détectera les erreurs SQL.
