Démarrage

Installer NiangPro, choisir un type de site, et faire le tour de ce qui a été généré.

Installation

Un nouveau projet se crée avec composer create-project :

composer create-project niangpro/niangpro mon-app
cd mon-app
./bin/niang serve

Le projet créé contient votre application ; le framework, niangpro/framework, est une dépendance installée dans vendor/ et se met à jour avec composer update niangpro/framework. Un projet créé avec la version 1.x était une copie du framework : pour le passer en 2.0, suivez UPGRADE.md dans le dépôt du framework.

./bin/niang serve lance php -S 127.0.0.1:8000 -t public — pas de dépendance à Apache ou Nginx pour développer en local. Un autre couple hôte/port peut être passé en argument : ./bin/niang serve 0.0.0.0:8080.

composer create-project crée aussi .env (copie de .env.example) avec une APP_KEY propre au projet — le secret qui signe les liens de réinitialisation de mot de passe et chiffre les cookies (voir Sécurité).

Choisir un type de site

À la fin de l'installation (ou de ./bin/niang new mon-app, l'équivalent utilisé à l'intérieur d'un projet NiangPro, qui lance composer create-project niangpro/niangpro dans un dossier frère), NiangPro pose une question interactive. Elle est portée par Niang\Core\Console\SiteTypePrompt et Niang\Core\Console\ProjectScaffolder, et affiche exactement ceci :

Quel type de site souhaitez-vous construire ?

  1) vitrine    Site vitrine / informationnel
  2) ecommerce  Boutique en ligne
  3) blog       Blog / magazine
  4) portfolio  Portfolio
  5) landing    Landing page one-page
  6) auth       Application avec comptes (inscription, connexion, espace membre)
  7) api        API REST (JSON, jetons, CORS, OpenAPI)
  8) saas       SaaS (organisations, membres, abonnements)
  9) minimal    Minimal — squelette de démonstration (défaut)

Votre choix [9] :

La liste vient de resources/scaffold/themes/* : chaque sous-dossier avec un theme.json valide y apparaît automatiquement (voir ProjectScaffolder::catalog()), minimal restant toujours en dernier et par défaut. Trois façons d'éviter la question :

• --type=blog sur la ligne de commande (./bin/niang new mon-app --type=blog) ;
• la variable d'environnement NIANG_SITE_TYPE (NIANG_SITE_TYPE=blog composer create-project niangpro/niangpro mon-app --no-interaction) ;
• lancer la commande dans un contexte non interactif (CI, pipe, docker run sans -t) : le squelette minimal est gardé silencieusement, sans poser la question.

Un type explicitement demandé (--type ou NIANG_SITE_TYPE) qui n'existe pas interrompt l'installation avec un message d'erreur listant les types disponibles — jamais de repli silencieux dans ce cas précis. Un thème installé ne fusionne pas avec le squelette minimal : il remplace ses vues, routes et assets de démonstration (voir ProjectScaffolder::install()).

Structure du projet généré

Votre code (app/, routes/, resources/views/...) et le framework (vendor/niangpro/framework) sont séparés. Avec le type minimal (la démo par défaut), un projet fraîchement créé contient :

mon-app/
├── app/
│   ├── Controllers/       HomeController, AuthController, PostController...
│   ├── Middleware/        VerifyCsrfToken, Authenticate, ThrottleRequests...
│   ├── Models/             User, Post, Comment, Tag...
│   ├── Providers/          AppServiceProvider
│   ├── Policies/           PostPolicy
│   ├── Requests/           ContactRequest (FormRequest)
│   ├── Resources/          PostResource (JsonResource)
│   ├── Jobs/, Listeners/, Mailables/
│   └── Console/Commands/   (créé par make:command, absent au départ)
├── config/                 app.php, auth.php, cors.php, security.php, session.php
├── database/
│   ├── migrations/
│   └── seeders/            DatabaseSeeder
├── public/
│   ├── index.php            point d'entrée HTTP
│   ├── favicon.svg, logo.svg
│   └── css/, js/
├── resources/views/         vues PHP natives (.php)
├── routes/web.php
├── storage/
│   ├── database.sqlite
│   ├── framework/           cache (routes, config)
│   └── logs/
├── tests/
│   ├── Feature/, Security/
│   └── bootstrap.php
├── bin/niang                 CLI
├── vendor/niangpro/framework/  le framework (composer update niangpro/framework)
├── composer.json
└── .env

Le framework reste lisible dans vendor/niangpro/framework/packages/ (14 paquets : core, http, database, auth...), mais ne se modifie pas : une mise à jour l'écraserait. Pour changer un comportement, passez par les points d'extension, un Service Provider ou un middleware. Tout le travail se fait dans app/, routes/, resources/views/ et database/.

Lancer le serveur de développement

./bin/niang serve

Affiche NiangPro démarre sur http://127.0.0.1:8000 puis reste au premier plan (Ctrl+C pour arrêter). C'est un simple appel à passthru('php -S ...') : aucun processus en arrière-plan, aucune configuration serveur à écrire pour développer localement.

Premier tour : routes et contrôleur

public/index.php est le seul point d'entrée HTTP. Il crée l'Application, charge routes/web.php, et lance le traitement de la requête :

require dirname(__DIR__) . '/vendor/autoload.php';

use Niang\Core\Application;

$app = new Application(dirname(__DIR__));

$app->loadRoutes(dirname(__DIR__) . '/routes/web.php');

$app->run();

routes/web.php reçoit une variable $router déjà prête à l'emploi :

use App\Controllers\HomeController;

$router->get('/', [HomeController::class, 'index']);
$router->get('/hello/{name}', [HomeController::class, 'hello']);
$router->post('/echo', [HomeController::class, 'echoBody']);

Le contrôleur correspondant étend Niang\Core\Controller :

namespace App\Controllers;

use Niang\Core\Controller;
use Niang\Core\Http\Request;
use Niang\Core\Http\Response;

class HomeController extends Controller
{
    public function index(): Response
    {
        return $this->view('home', [
            'title' => 'Bienvenue sur NiangPro',
            'framework' => 'NiangPro',
        ]);
    }

    public function hello(string $name): Response
    {
        return $this->json([
            'message' => "Bonjour, $name !",
        ]);
    }
}

Remarquez hello(string $name) : $name n'est déclaré nulle part comme dépendance du container, c'est le nom du paramètre de route {name} résolu directement par réflexion — voir le Container pour le détail de cette résolution.

Et ensuite ?

• Concepts fondamentaux — le cycle de vie d'une requête, le Container, les Service Providers.
• Routing — paramètres, contraintes, groupes, domaines, routes ressource.