nodefony 7.0.2 → 10.0.0-alpha.2

package/templates/module/packages/tsconfig.declarations.json.tpl

@@ -0,0 +1,19 @@
+{
+  "extends": "./tsconfig.json",
+  "include": ["index.ts", "nodefony/**/*.ts"],
+  "exclude": [
+    "node_modules",
+    "dist",
+    "tests/**",
+    "**/*.test.ts",
+    "**/*.spec.ts"
+  ],
+  "compilerOptions": {
+    "declaration": true,
+    "emitDeclarationOnly": true,
+    "declarationDir": "./dist/types",
+    "noUnusedLocals": false,
+    "noUnusedParameters": false,
+    "skipLibCheck": true
+  }
+}

package/templates/module/packages/tsconfig.tests.json.tpl

@@ -0,0 +1,11 @@
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "noEmit": true,
+    "types": ["node", "vitest/globals"],
+    "noUnusedLocals": false,
+    "noUnusedParameters": false
+  },
+  "include": ["tests/**/*.ts", "nodefony/tests/**/*.ts", "vitest.config.ts"],
+  "exclude": ["node_modules", "dist"]
+}

package/templates/module/service/nodefony/interfaces/I__PASCAL__Service.ts.tpl

@@ -0,0 +1,14 @@
+/**
+ * API publique de `<%= it.pascal %>Service` (injectable, nom `<%= it.name %>`).
+ *
+ * L'interface est le CONTRAT : ce que les autres modules (et Studio) peuvent
+ * appeler. Tout ce qui n'est pas ici est un détail d'implémentation, libre de
+ * changer.
+ */
+export interface I<%= it.pascal %>Service {
+  /** Snapshot de lecture — état courant du service. */
+  status(): { ready: boolean };
+
+  /** Exemple de méthode métier — à remplacer par la vôtre. */
+  greet(who?: string): string;
+}

package/templates/module/service/nodefony/interfaces/index.ts.tpl

@@ -0,0 +1 @@
+export type { I<%= it.pascal %>Service } from "./I<%= it.pascal %>Service";

package/templates/module/service/nodefony/service/__PASCAL__Service.ts.tpl

@@ -0,0 +1,116 @@
+import {
+  Service,
+  Module,
+  Container,
+  Event,
+  extend,
+  injectable,
+} from "nodefony";
+import type { I<%= it.pascal %>Service } from "../interfaces/I<%= it.pascal %>Service";
+import defaultConfig, { type <%= it.pascal %>Config } from "../config/config";
+
+/**
+ * ⚡ **Tu veux un service ? Ne recopie pas ce fichier — génère-le :**
+ *
+ * ```bash
+ * npx nodefony create service <Nom>                  # la classe + sa déclaration
+ * npx nodefony create service <Nom> --inject <Autre> # + la dépendance écrite
+ * ```
+ *
+ * Le générateur écrit la version COURANTE du framework et déclare le service sur
+ * le module ; recopié à la main, il naît déjà décalé et personne ne le signale.
+ * Ce fichier reste là pour se LIRE — comprendre ce qu'est un service — pas pour
+ * se dupliquer.
+ *
+ *
+ * Service principal du module — la logique vit ici, pas dans les controllers
+ * (un controller traduit du HTTP/WS ; un service, lui, est réutilisable par la
+ * CLI, un job, un autre module).
+ *
+ * Cycle : `constructor` (fusion défauts + config de l'app) → `init`
+ * (branchements kernel) → méthodes métier.
+ *
+ * Un service porte DEUX noms, et c'est normal :
+ *   `@injectable()`             → nomme la CLASSE (`<%= it.pascal %>Service`),
+ *                                 c'est ce qu'on écrit dans `@inject("…")`
+ *   `super("<%= it.name %>", …)` → nomme l'INSTANCE, sa clé dans le conteneur,
+ *                                 c'est ce qu'on écrit dans `kernel.get("…")`
+ * Les deux mènent à la MÊME instance : le conteneur les réconcilie via la classe.
+ * (Le décorateur ne peut pas deviner la clé — il s'exécute au chargement de la
+ * classe, le `super()` seulement à la construction.)
+ *
+ * ⚠️ Ne JAMAIS redéclarer `options` comme propriété : la classe `Service` parente
+ * l'assigne déjà via le 4ᵉ argument du `super()`. On garde une référence typée
+ * `cfg` pour lire la config sans se battre avec TypeScript.
+ *
+ * POUR L'UTILISER AILLEURS, deux voies, toutes deux légales :
+ *
+ * ```ts
+ * // 1. INJECTION par le constructeur — la dépendance est DÉCLARÉE, donc le
+ * //    conteneur l'ordonnance et elle se voit dans la signature (nom de CLASSE).
+ * import { inject, injectable, Service, Module } from "nodefony";
+ *
+ * @injectable()
+ * class ReportService extends Service {
+ *   constructor(
+ *     module: Module,
+ *     @inject("<%= it.pascal %>Service") private <%= it.name %>: <%= it.pascal %>Service,
+ *   ) {
+ *     super("report", module.container, module.notificationsCenter);
+ *   }
+ * }
+ *
+ * // 2. RÉSOLUTION par le conteneur, pour une dépendance tardive ou optionnelle
+ * //    (nom d'INSTANCE).
+ * const <%= it.name %> = this.container.get("<%= it.name %>");
+ * ```
+ */
+@injectable()
+class <%= it.pascal %>Service extends Service implements I<%= it.pascal %>Service {
+  module: Module;
+  private readonly cfg: <%= it.pascal %>Config;
+
+  constructor(module: Module) {
+    const merged = extend(
+      true,
+      {},
+      defaultConfig,
+      module.options ?? {},
+    ) as <%= it.pascal %>Config;
+    super(
+      "<%= it.name %>",
+      module.container as Container,
+      module.notificationsCenter as Event,
+      merged,
+    );
+    this.module = module;
+    this.cfg = merged;
+  }
+
+  /**
+   * Hook de démarrage d'un service : appelé UNE fois par le kernel, après la
+   * construction. C'est ici qu'on s'abonne aux événements du kernel — jamais
+   * dans le constructeur, où le kernel n'est pas encore prêt.
+   *
+   * ⚠️ Il s'appelle `init`, pas `initialize`. Le kernel ne cherche que `init`
+   * (`guardServiceInitialize`) : une méthode nommée `initialize` sur un service
+   * n'est JAMAIS appelée, et rien ne le signale — le code y dort en silence.
+   * (`initialize` existe bien, mais sur un CONTROLLER, où il tourne à CHAQUE
+   * requête : deux cycles de vie distincts, d'où deux noms.)
+   */
+  async init(): Promise<this> {
+    this.log("service <%= it.name %> initialisé", "DEBUG");
+    return this;
+  }
+
+  /** Exemple de méthode métier — à remplacer par la vôtre. */
+  greet(who = "monde"): string {
+    return `${this.cfg.greeting}, ${who} !`;
+  }
+
+  status(): { ready: boolean } {
+    return { ready: this.cfg.enabled };
+  }
+}
+
+export default <%= it.pascal %>Service;

package/templates/service/nodefony/interfaces/I__PASCAL__Service.ts.tpl

@@ -0,0 +1,19 @@
+/**
+ * API publique de `<%= it.pascal %>Service` (injectable, clé de conteneur
+ * `<%= it.camel %>`).
+ *
+ * L'interface est le CONTRAT : ce que les autres services, controllers et
+ * commandes peuvent appeler. Tout ce qui n'est pas ici est un détail
+ * d'implémentation, libre de changer.
+ */
+export interface I<%= it.pascal %>Service {
+  /** Snapshot de lecture — état courant du service. */
+  status(): { ready: boolean };
+
+  /** Exemple de méthode métier — à remplacer par la vôtre. */
+  greet(who?: string): string;
+<% if (it.inject) { %>
+
+  /** Délègue à `<%= it.inject.pascal %>`, injecté par le constructeur. */
+  from<%= it.inject.pascal %>(): Promise<unknown>;
+<% } %>}

package/templates/service/nodefony/service/__PASCAL__Service.ts.tpl

@@ -0,0 +1,136 @@
+import { Service, Module, Container, Event, injectable<% if (it.inject) { %>, inject<% } %> } from "nodefony";
+import type { I<%= it.pascal %>Service } from "../interfaces/I<%= it.pascal %>Service";
+<% if (it.inject) { %>import <%= it.inject.pascal %> from "./<%= it.inject.pascal %>";
+<% } %>
+
+/**
+ * ⚡ **Tu veux un service ? Ne recopie pas ce fichier — génère-le :**
+ *
+ * ```bash
+ * npx nodefony create service <Nom>                  # la classe + sa déclaration
+ * npx nodefony create service <Nom> --inject <Autre> # + la dépendance écrite
+ * ```
+ *
+ * Le générateur écrit la version COURANTE du framework et déclare le service sur
+ * le module ; recopié à la main, il naît déjà décalé et personne ne le signale.
+ * Ce fichier reste là pour se LIRE — comprendre ce qu'est un service — pas pour
+ * se dupliquer.
+ *
+ *
+ * <%= it.description %>.
+ *
+ * La logique métier vit ICI, pas dans un controller : un controller traduit du
+ * HTTP/WS ; un service, lui, est réutilisable par n'importe quel controller,
+ * une commande CLI ou un autre module — la même méthode sert tous les
+ * transports, sans être réécrite pour chacun.
+ *
+ * Un service porte DEUX noms, et c'est normal :
+ *   `@injectable()`                → nomme la CLASSE (`<%= it.pascal %>Service`),
+ *                                    c'est ce qu'on écrit dans `@inject("…")`
+ *   `super("<%= it.camel %>", …)`  → nomme l'INSTANCE, sa clé dans le conteneur,
+ *                                    c'est ce qu'on écrit dans `kernel.get("…")`
+ * Les deux mènent à la MÊME instance : le conteneur les réconcilie via la classe.
+ * (Le décorateur ne peut pas deviner la clé — il s'exécute au chargement de la
+ * classe, le `super()` seulement à la construction.)
+ *
+ * Une classe à méthodes `static`, ou un objet exporté, COMPILE et marche — et
+ * reste invisible au framework : ni conteneur, ni journal (`this.log`), ni
+ * événements. C'est `@injectable()` + `extends Service` qui font qu'un service
+ * EST un service Nodefony.
+ *
+ * POUR L'UTILISER AILLEURS, deux voies, toutes deux légales :
+ *
+<% if (it.inject) { %> * 1. INJECTION par le constructeur — c'est CE QUE FAIT le constructeur
+ *    ci-dessous avec `<%= it.inject.pascal %>` : la dépendance est DÉCLARÉE, donc le
+ *    conteneur l'ordonnance et elle se voit dans la signature. Le décorateur
+ *    prend le nom de la CLASSE (`<%= it.inject.pascal %>`), pas la clé d'instance.
+ *
+ * ```ts
+ * // 2. RÉSOLUTION par le conteneur — utile quand la dépendance est tardive ou
+ * //    optionnelle. Ici c'est le nom de l'INSTANCE.
+ * const <%= it.camel %> = this.container.get("<%= it.camel %>");
+ * ```
+<% } else { %> * ```ts
+ * // 1. INJECTION par le constructeur — la dépendance est DÉCLARÉE, donc le
+ * //    conteneur l'ordonnance et elle se voit dans la signature. Le décorateur
+ * //    prend le nom de la CLASSE.
+ * import { inject, injectable, Service, Module } from "nodefony";
+ *
+ * @injectable()
+ * class ReportService extends Service {
+ *   constructor(
+ *     module: Module,
+ *     @inject("<%= it.pascal %>Service") private <%= it.camel %>: <%= it.pascal %>Service,
+ *   ) {
+ *     super("report", module.container, module.notificationsCenter);
+ *   }
+ * }
+ *
+ * // 2. RÉSOLUTION par le conteneur — utile quand la dépendance est tardive ou
+ * //    optionnelle. Ici c'est le nom de l'INSTANCE.
+ * const <%= it.camel %> = this.container.get("<%= it.camel %>");
+ * ```
+ *
+ * Le scaffold écrit la voie 1 pour toi : `nodefony create service <nom>
+ * --inject <%= it.pascal %>Service` rend le constructeur déjà injecté.
+<% } %> */
+@injectable()
+class <%= it.pascal %>Service extends Service implements I<%= it.pascal %>Service {
+  module: Module;
+
+  constructor(
+    module: Module,
+<% if (it.inject) { %>    // La dépendance passe par le CONSTRUCTEUR : le conteneur la construit avant
+    // celui-ci et l'ordonnance. `@inject` prend le nom de la CLASSE — la clé
+    // d'instance (`"<%= it.inject.key %>"`) ne sert qu'à `container.get`.
+    @inject("<%= it.inject.pascal %>") private readonly <%= it.inject.camel %>: <%= it.inject.pascal %>,
+<% } %>  ) {
+    super(
+      "<%= it.camel %>",
+      module.container as Container,
+      module.notificationsCenter as Event,
+    );
+    this.module = module;
+  }
+
+  /**
+   * Hook de démarrage d'un service : appelé UNE fois par le kernel, après la
+   * construction. C'est ici qu'on s'abonne aux événements du kernel — jamais
+   * dans le constructeur, où le kernel n'est pas encore prêt.
+   *
+   * ⚠️ Il s'appelle `init`, pas `initialize`. Le kernel ne cherche que `init`
+   * (`guardServiceInitialize`) : une méthode nommée `initialize` sur un service
+   * n'est JAMAIS appelée, et rien ne le signale — le code y dort en silence.
+   * (`initialize` existe bien, mais sur un CONTROLLER, où il tourne à CHAQUE
+   * requête : deux cycles de vie distincts, d'où deux noms.)
+   */
+  async init(): Promise<this> {
+    this.log("service <%= it.camel %> initialisé", "DEBUG");
+    return this;
+  }
+
+  /** Exemple de méthode métier — à remplacer par la vôtre. */
+  greet(who = "monde"): string {
+    return `Bonjour, ${who} !`;
+  }
+<% if (it.inject) { %>
+
+  /**
+   * Délègue au service injecté — remplace ce corps par ta logique.
+   *
+   * Rien à résoudre ici : `this.<%= it.inject.camel %>` est déjà l'instance que le
+   * conteneur a construite. C'est toute la différence avec
+   * `container.get("<%= it.inject.key %>")`, qui cherche à l'exécution et rend
+   * `undefined` en silence si le service n'est pas enregistré.
+   */
+  async from<%= it.inject.pascal %>(): Promise<unknown> {
+    return this.<%= it.inject.camel %>.<%= it.inject.method %>();
+  }
+<% } %>
+
+  status(): { ready: boolean } {
+    return { ready: true };
+  }
+}
+
+export default <%= it.pascal %>Service;

package/templates/service/tests/__PASCAL__Service.test.ts.tpl

@@ -0,0 +1,53 @@
+import { describe, it, expect } from "vitest";
+import { createTestModule } from "nodefony/testing";
+import <%= it.pascal %>Service from "../nodefony/service/<%= it.pascal %>Service";
+<% if (it.inject) { %>import <%= it.inject.pascal %> from "../nodefony/service/<%= it.inject.pascal %>";
+<% } %>
+/**
+ * <%= it.pascal %>Service, éprouvé SEUL — sans serveur, sans base, sans port.
+ *
+ * `createTestModule()` (sous-chemin `nodefony/testing`) rend le module jetable
+ * qu'un service réclame en argument. C'est ce qui permet d'éprouver une règle
+ * métier en quelques millisecondes, là où passer par HTTP exerce toute la
+ * chaîne sans rien dire de CETTE responsabilité.
+ *
+ * ⚠️ Les assertions ci-dessous ne portent QUE sur ce qui survit à ta logique
+ * (le nom du service, son état). Le gabarit t'invite à remplacer sa méthode
+ * d'exemple : un test écrit sur elle serait rouge à ta première modification.
+ * **Ajoute tes propres cas** au dernier `describe` — c'est là que ce fichier
+ * devient utile.
+ */
+
+/**
+ * Construit le service sur un module neuf.
+<% if (it.inject) { %> *
+ * La dépendance est passée À LA MAIN : la résolution par le conteneur
+ * (`@inject`) réclame un kernel vivant, absent d'un test unitaire. C'est tout
+ * l'intérêt de l'injection par constructeur — et c'est ce qui te permettra d'y
+ * glisser un objet qui joue le rôle du vrai service pour éprouver un cas limite.
+<% } %> */
+const build = (): <%= it.pascal %>Service => {
+  const module = createTestModule();
+  return new <%= it.pascal %>Service(module<% if (it.inject) { %>, new <%= it.inject.pascal %>(module)<% } %>);
+};
+
+describe("<%= it.pascal %>Service", () => {
+  it("se construit sur un module jetable et porte sa clé de conteneur", () => {
+    const service = build();
+    // La clé d'instance vient de `super("<%= it.camel %>", …)` : c'est elle
+    // qu'on écrit dans `container.get("…")`.
+    expect(service.name).toBe("<%= it.camel %>");
+    expect(service.status()).toEqual({ ready: true });
+  });
+
+  it("deux instances sont ISOLÉES — un test ne pollue pas le suivant", () => {
+    const a = build();
+    const b = build();
+    expect(a).not.toBe(b);
+    expect(a.container).not.toBe(b.container);
+  });
+
+  describe("ta logique métier", () => {
+    it.todo("décrit ce que ton service doit garantir");
+  });
+});

package/templates/shared/front-entry/angular/frontend/src/main.ts.tpl

@@ -0,0 +1,17 @@
+import { bootstrapApplication } from "@angular/platform-browser";
+import { provideZonelessChangeDetection } from "@angular/core";
+<% if (it.complete) { %>// La politique temps réel du framework s'installe comme tout le reste en
+// Angular : un FOURNISSEUR d'injection. C'est ici, et ici seulement, que
+// l'adresse du serveur est écrite — les composants n'en connaissent aucune, et
+// le framework n'en devine aucune : une adresse devinée marche en développement
+// et se trompe en production. Le fournisseur ouvre la connexion HORS ZONE.
+import { provideNodefony } from "nodefony/angular";
+<% } %>import { AppComponent } from "./app/app.component";
+
+// Zoneless (Angular 20+) : pas de zone.js, détection pilotée par signals.
+bootstrapApplication(AppComponent, {
+  providers: [
+    provideZonelessChangeDetection(),
+<% if (it.complete) { %>    provideNodefony({ url: "/api/live/realtime" }),
+<% } %>  ],
+}).catch((err) => console.error(err));

package/templates/shared/front-entry/react/frontend/src/main.tsx.tpl

@@ -0,0 +1,11 @@
+import { StrictMode } from "react";
+import { createRoot } from "react-dom/client";
+import { App } from "./App";
+
+const rootEl = document.getElementById("root");
+if (!rootEl) throw new Error("#root not found");
+createRoot(rootEl).render(
+  <StrictMode>
+    <App />
+  </StrictMode>,
+);

package/templates/shared/front-entry/svelte/frontend/src/main.ts.tpl

@@ -0,0 +1,13 @@
+import { mount } from "svelte";
+<% if (it.complete) { %>// La politique temps réel du framework. Svelte n'a pas de contexte applicatif :
+// elle s'écrit ici, comme ce qu'elle est — une configuration de module, posée
+// AVANT le montage. C'est le seul endroit où l'adresse du serveur est écrite ;
+// le framework n'en devine aucune : une adresse devinée marche en développement
+// et se trompe en production.
+import { configureNodefony } from "nodefony/svelte";
+<% } %>import App from "./App.svelte";
+
+const el = document.getElementById("app");
+if (!el) throw new Error("#app not found");
+<% if (it.complete) { %>configureNodefony({ url: "/api/live/realtime" });
+<% } %>mount(App, { target: el });

package/templates/shared/front-entry/vue/frontend/src/main.ts.tpl

@@ -0,0 +1,12 @@
+import { createApp } from "vue";
+<% if (it.complete) { %>// La politique temps réel du framework s'installe comme tout le reste en Vue :
+// un PLUGIN. C'est ici, et ici seulement, que l'adresse du serveur est écrite —
+// les composables de la page n'en connaissent aucune, et le framework n'en
+// devine aucune : une adresse devinée marche en développement et se trompe en
+// production.
+import { nodefonyVue } from "nodefony/vue";
+<% } %>import App from "./App.vue";
+
+const el = document.getElementById("app");
+if (!el) throw new Error("#app not found");
+<% if (it.complete) { %>createApp(App).use(nodefonyVue, { url: "/api/live/realtime" }).mount(el);<% } else { %>createApp(App).mount(el);<% } %>

package/templates/shared/front-registrar/nodefony/frontend/register__PASCAL__Entry.ts.tpl

@@ -0,0 +1,40 @@
+import type { Module } from "nodefony";
+import type { FrontendService } from "@nodefony/frontend";
+
+/**
+ * Déclare l'entry Vite « <%= it.entryName %> » auprès de `@nodefony/frontend`.
+ *
+ * À appeler depuis le hook `onKernelBoot()` du module propriétaire — AVANT
+ * `onKernelReady` : le superviseur Vite démarre avec la liste COMPLÈTE des
+ * entries (en dev il compile toutes les pages du process dans UN serveur Vite ;
+ * en prod chaque entry a son bundle fingerprinté, servi en statique).
+ *
+ * Champs de l'entry :
+ *  - `type`   : pilote du framework (`react19` | `vue3` | `angular`) — choisit
+ *    le plugin Vite injecté dans la config GÉNÉRÉE (vite.config.generated.mjs,
+ *    régénérée à chaque boot dev — ne jamais l'éditer à la main) ;
+ *  - `entry`  : point d'entrée compilé, RELATIF au dossier du module ;
+ *  - `root`   : racine Vite du module (contient index.html + src/) ;
+ *  - `outDir` : sortie du build prod (montée en statique par le framework) ;
+ *  - `name`   : nom de l'entry — le MÊME que celui passé à
+ *    `renderDocument("<%= it.entryName %>", nonce, hôte)` par le controller ;
+ *  - `apiProxyPaths` : chemins re-proxifiés de Vite vers Nodefony en dev —
+ *    sans eux, un `fetch("/api/…")` depuis la page servie par Vite reçoit le
+ *    SPA-fallback HTML de Vite au lieu du JSON (piège n°1 du multi-origine).
+ */
+export function register<%= it.pascal %>Entry(module: Module): void {
+  const svc = module.kernel?.container?.get("frontend") as
+    FrontendService | undefined;
+  if (!svc) {
+    module.log("@nodefony/frontend service not registered", "ERROR");
+    return;
+  }
+  svc.registerEntry(module, {
+    type: "<%= it.front.type %>",
+    entry: "<%= it.front.entry %>",
+    root: "./frontend",
+    outDir: "./public/dist",
+    name: "<%= it.entryName %>",
+    apiProxyPaths: ["/api"],
+  });
+}

package/templates/shared/front-shell/frontend/index.html.tpl

@@ -0,0 +1,39 @@
+<!doctype html>
+<!--
+  Coquille HTML de ton app — TA page, pas celle du framework : ajoute ici tes
+  meta, polices, favicons, scripts externes. Le framework injecte ses balises
+  (entry Vite + HMR en dev, bundle fingerprinté en prod, nonce CSP propagé)
+  au marqueur ci-dessous — laisse-le en place.
+-->
+<!--
+  `lang` n'est pas décoratif : il décide de l'accent avec lequel une synthèse
+  vocale lit ta page, et de la langue que déclare ton document aux moteurs de
+  recherche. Il valait `en` sur une page dont le contenu est en français —
+  change-le pour la langue de TON application, ne le laisse jamais mentir.
+-->
+<html lang="fr">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width,initial-scale=1" />
+    <title><%= it.appName %></title>
+    <!-- Résumé affiché par les moteurs de recherche sous ton titre. Sans lui,
+         ils en fabriquent un depuis le texte de la page — rarement à ton avantage. -->
+    <meta
+      name="description"
+      content="<%= it.appName %> — application Nodefony."
+    />
+    <!-- Dit au navigateur que la page sait s'afficher dans les deux thèmes :
+         sans cela, les contrôles natifs (champs, barres) restent clairs sur un
+         fond sombre. -->
+    <meta name="color-scheme" content="light dark" />
+    <!-- favicon inline (⬡) : remplace par ton fichier — évite le 404 /favicon.ico -->
+    <link
+      rel="icon"
+      href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Ctext y='13' font-size='13'%3E%E2%AC%A1%3C/text%3E%3C/svg%3E"
+    />
+    <!--nodefony:frontend-->
+  </head>
+  <body>
+    <%= it.front.mountNode %>
+  </body>
+</html>

package/templates/shared/ng-app-tsconfig/frontend/tsconfig.app.json.tpl

@@ -0,0 +1,18 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "lib": ["ES2022", "DOM", "DOM.Iterable"],
+    "experimentalDecorators": true,
+    "emitDecoratorMetadata": true,
+    "useDefineForClassFields": false,
+    "strict": true,
+    "skipLibCheck": true,
+    "esModuleInterop": true,
+    "types": []
+  },
+  "angularCompilerOptions": { "strictTemplates": true },
+  "files": ["src/main.ts"],
+  "include": ["src/**/*.ts"]
+}

package/templates/shared/svelte-shim/frontend/src/env.d.ts.tpl

@@ -0,0 +1,12 @@
+/// <reference types="vite/client" />
+
+/**
+ * Shim d'environnement Svelte (standard Vite) : permet à tsgo/tsc de résoudre
+ * les imports de composants. Le typecheck de l'INTÉRIEUR des .svelte relève
+ * de svelte-check.
+ */
+declare module "*.svelte" {
+  import type { Component } from "svelte";
+  const component: Component;
+  export default component;
+}

package/templates/shared/vue-shim/frontend/src/env.d.ts.tpl

@@ -0,0 +1,15 @@
+/// <reference types="vite/client" />
+
+/**
+ * Shim d'environnement Vue (standard Vite) : permet à tsgo/tsc de résoudre
+ * les imports de SFC. Le typecheck de l'INTÉRIEUR des .vue relève de vue-tsc.
+ */
+declare module "*.vue" {
+  import type { DefineComponent } from "vue";
+  const component: DefineComponent<
+    Record<string, never>,
+    Record<string, never>,
+    unknown
+  >;
+  export default component;
+}

package/.yarnclean

@@ -1,45 +0,0 @@
-# test directories
-__tests__
-test
-tests
-powered-test
-
-# asset directories
-docs
-doc
-website
-images
-assets
-
-# examples
-example
-examples
-
-# code coverage directories
-coverage
-.nyc_output
-
-# build scripts
-Makefile
-Gulpfile.js
-Gruntfile.js
-
-# configs
-appveyor.yml
-circle.yml
-codeship-services.yml
-codeship-steps.yml
-wercker.yml
-.tern-project
-.gitattributes
-.editorconfig
-.*ignore
-.eslintrc
-.jshintrc
-.flowconfig
-.documentup.json
-.yarn-metadata.json
-.travis.yml
-
-# misc
-*.md