TypeflowTransformations JSON typées

Un langage de mapping déclaratif pour JSON — chemins validés, types de sortie inférés, et des erreurs de compilation plutôt que des incidents en production.

Essayer le Playground

Bien démarrer

GitHub

🧭

Les chemins sont validés

Chaque chemin d'un mapping est vérifié contre le type d'entrée. Une coquille comme user.emial est une erreur de compilation avec une suggestion « Did you mean 'email'? ».

Chemins & optionnalité

🧠

Les types de sortie sont inférés

Le compilateur dérive un type de sortie précis depuis le mapping — optionnalité comprise — et émet des déclarations .d.typeflow.ts pour des imports entièrement typés.

Imports typés

🛡️

L'optionnalité est imposée

Accéder à un chemin optionnel sans ?. est une erreur. Ajouter un défaut ?? retire l'optionnalité du type de sortie inféré.

Voir le diagnostic

📦

Les mappings sont des artefacts

Les mappings compilés sont sérialisables en JSON et tournent sur un petit interpréteur déterministe sans dépendance — Node, Bun, navigateurs, CI.

Utiliser depuis le code

🧩

Apportez vos fonctions

Une bibliothèque standard de niveau JSONata, plus les définitions fn, les déclarations use et defineFunction — toutes vérifiées à la compilation comme les natives.

Fonctions personnalisées

🔁

Vous venez de JSONata ou jq ?

typeflow convert réécrit chemins, prédicats, lambdas et la stdlib en Typeflow typé — en parallèle sur tous les fichiers — et dit exactement ce qu'il n'a pas pu convertir.

La commande convert

Essayez — cette page exécute le vrai compilateur

Tout ce qui suit est vivant : modifiez le mapping ou l'entrée et regardez la sortie, le type inféré et les diagnostics se mettre à jour à chaque frappe. Pas de serveur — le compilateur et le runtime tournent dans votre navigateur.

Mapping✔Playground ↗

input user: {
  id: number,
  firstName: string,
  lastName: string,
  role: "admin" | "member" | "guest",
  contact?: { email?: string },
  labels: { name: string, active: boolean }[],
  scores: number[],
}

fn grade(score: number) = score >= 15 ? "A" : score >= 10 ? "B" : "C"

map {
  id: user.id,
  fullName: user.firstName + " " + user.lastName,
  isAdmin: user.role == "admin",
  email: user.contact?.email ?? "unknown",
  activeTags: user.labels[active].name,
  results: user.scores -> { value: $, grade: grade($) },
}

JSON d'entrée

{
  "id": 42,
  "firstName": "Ada",
  "lastName": "Lovelace",
  "role": "admin",
  "contact": {},
  "labels": [
    { "name": "founder", "active": true },
    { "name": "legacy", "active": false }
  ],
  "scores": [16, 9, 12]
}

Sortie

{
  "id": 42,
  "fullName": "Ada Lovelace",
  "isAdmin": true,
  "email": "unknown",
  "activeTags": [
    "founder"
  ],
  "results": [
    {
      "value": 16,
      "grade": "A"
    },
    {
      "value": 9,
      "grade": "C"
    },
    {
      "value": 12,
      "grade": "B"
    }
  ]
}

type inféré

{
  id: number;
  fullName: string;
  isAdmin: boolean;
  email: string;
  activeTags: string[];
  results: { value: number; grade: "A" | "B" | "C" }[];
}

Les coquilles sont des erreurs de compilation, pas des incidents en production

Ce mapping contient deux bugs classiques : une propriété mal orthographiée et un accès optionnel non protégé. Dans une fonction ordinaire, ils partiraient en production comme des undefined silencieux — ici ils ne quittent jamais votre éditeur. Corrigez-les en direct : emial → email, et ajoutez ?. + ?? sur la seconde ligne.

Mapping✖ 2Playground ↗

input user: {
  email: string,
  contact?: { phone: string },
}

map {
  mail: user.emial,
  phone: user.contact.phone,
}

JSON d'entrée

{ "email": "ada@lovelace.dev", "contact": { "phone": "+44" } }

Sortie

// Corrigez les erreurs du mapping pour voir la sortie.

type inféré{ mail: any; phone: string }

7:14errorTF2002Property 'emial' does not exist on type '{ email: string; contact?: { phone: string } }'. Did you mean 'email'?
8:23errorTF2003Object is possibly 'undefined'.
indice: Use the optional access operator: '?.phone', or provide a default with '??'.

Chaque diagnostic a un code stable, un indice, et une reproduction vivante dans la référence des diagnostics.

Tout le langage est documenté depuis la source

Les pages d'opérateurs, la référence des fonctions et celle des diagnostics sont générées depuis les définitions mêmes que le compilateur exécute — signatures, docs et exemples ne peuvent pas dériver de l'implémentation. Le build échoue si un exemple cesse de compiler.

fonctions natives

typées, documentées, vivantes

opérateurs & constructions

chacun avec un playground

diagnostics

documentés avec repros vivantes

dépendance du runtime

Node, Bun, navigateurs, CI

Pourquoi pas JSONata, jq, ou une simple fonction ?

	Typeflow	JSONata	jq	Zod	Fonction TS
Transformation déclarative	✅	✅	✅	❌ (validation)	❌
Chemins d'entrée validés statiquement	✅	❌	❌	n/a	✅
Type de sortie inféré	✅	❌	❌	⚠️ déclaré	✅
Artefact sérialisable / sandboxable	✅	✅	✅	❌	❌
Déterministe par construction	✅	⚠️	✅	n/a	❌

Zod est une entrée naturelle de Typeflow, pas un concurrent : Zod répond « est-ce un X ? » ; Typeflow répond « comment X devient-il Y, et cette conversion est-elle sûre ? »

Démarrez en une minute

console

$ bun add -d typeflowjs
$ bunx typeflow init                 # génère un mapping d'exemple
$ bunx typeflow check                # diagnostics façon tsc
$ bunx typeflow run user.typeflow --input data.json

Lire le guide Ouvrir le playground Parcourir les fonctions