@aurabase/aurabase-js 0.3.1 → 0.4.1

package/packages/core/package.json

@@ -1,57 +0,0 @@
-{
-  "name": "@aurabase/core",
-  "version": "0.3.0",
-  "description": "Cœur du SDK Aurabase : fetch résilient, erreurs, stores auth, types de réponse (infrastructure interne)",
-  "type": "module",
-  "main": "dist/index.cjs",
-  "module": "dist/index.js",
-  "types": "dist/index.d.ts",
-  "exports": {
-    ".": {
-      "import": {
-        "types": "./dist/index.d.ts",
-        "default": "./dist/index.js"
-      },
-      "require": {
-        "types": "./dist/index.d.cts",
-        "default": "./dist/index.cjs"
-      }
-    }
-  },
-  "sideEffects": false,
-  "files": [
-    "dist",
-    "README.md",
-    "LICENSE"
-  ],
-  "engines": {
-    "node": ">=20.0.0"
-  },
-  "license": "MIT",
-  "author": "Aurabase",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/daylami555/aurabase.git",
-    "directory": "aurabase-js/packages/core"
-  },
-  "homepage": "https://github.com/daylami555/aurabase/tree/main/aurabase-js/packages/core#readme",
-  "bugs": {
-    "url": "https://github.com/daylami555/aurabase/issues"
-  },
-  "keywords": [
-    "aurabase",
-    "baas",
-    "sdk",
-    "core"
-  ],
-  "scripts": {
-    "build": "tsup",
-    "test": "vitest run",
-    "typecheck": "tsc --noEmit"
-  },
-  "devDependencies": {
-    "tsup": "catalog:",
-    "typescript": "catalog:",
-    "vitest": "catalog:"
-  }
-}

package/packages/db/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Aurabase
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/packages/db/README.md

@@ -1,152 +0,0 @@
-# @aurabase/db
-
-Service base de données du SDK Aurabase : query builder typé, style PostgREST, avec inférence de types sur `select()`/`insert()`/`update()`.
-
-![npm](https://img.shields.io/npm/v/@aurabase/db) ![license](https://img.shields.io/badge/license-MIT-blue)
-
-> Pre-release — pas encore publié sur npm.
-
-Fait partie du SDK **[aurabase](../aurabase)**. Installé automatiquement avec `aurabase` ; ce package est publié séparément pour un usage ciblé / tree-shaking.
-
-## Installation
-
-```bash
-npm i @aurabase/db
-```
-
-> Dépend de `@aurabase/core`. Déjà inclus si vous utilisez le package `aurabase` — cette installation ciblée sert à composer votre propre client ou à limiter la taille du bundle.
-
-## Usage
-
-`DatabaseService` est exposé par le client principal sous `aura.db`. Pour l'inférence de types (colonnes, embeds, `Insert`/`Update`), passez un type `Database` généré à `createClient<Database>(...)` (voir [`@aurabase/gen`](../gen)).
-
-```ts
-import { createClient } from 'aurabase'
-import type { Database } from './database.types' // généré par @aurabase/gen, optionnel
-
-const aura = createClient<Database>('http://localhost:8080', 'my-project', 'aura_anon_xxx')
-```
-
-### Select, filtres, embeds
-
-```ts
-const { data, error } = await aura.db
-  .from('posts')
-  .select('id,title,author:authors(*)') // embed PostgREST-like (alias:table(*)) — typé si Database est fourni
-  .eq('published', true)
-  .order('created_at', 'desc')
-  .limit(10)
-```
-
-Filtres disponibles : `eq`, `neq`, `gt`, `gte`, `lt`, `lte`, `like`, `ilike`, `is('null' | 'not.null' | 'true' | 'false' | 'unknown')`, `in`, `notIn`, `or([{ column, op, value }])`, `contains`, `containedBy`, `overlaps`, `rangeGt`/`rangeGte`/`rangeLt`/`rangeLte`/`rangeAdjacent`, `isDistinct`, `not(column, op, value)`, `filter(column, op, value)`, `match(obj)`, `textSearch(column, query, { type, config })`, `likeAllOf`/`likeAnyOf`/`ilikeAllOf`/`ilikeAnyOf`.
-
-```ts
-await aura.db
-  .from('posts')
-  .or([
-    { column: 'published', op: 'eq', value: true },
-    { column: 'author_id', op: 'eq', value: 'user-id' },
-  ])
-  .textSearch('title', 'aurabase', { type: 'websearch' })
-```
-
-Modificateurs : `order(column, 'asc' | 'desc')`, `limit(n)`, `offset(n)`, `cursor(nextCursor)`, `count('exact' | ...)`, `single()`, `maybeSingle()`, `throwOnError()`.
-
-```ts
-const postId = 'post-id'
-const { data: post } = await aura.db.from('posts').eq('id', postId).single()
-
-const { data: maybePost } = await aura.db.from('posts').eq('slug', 'unknown').maybeSingle()
-
-const firstPage = await aura.db.from('posts').order('id').limit(20)
-const secondPage = await aura.db.from('posts').order('id').cursor(firstPage.meta?.next_cursor ?? '')
-```
-
-### Mutations — `update`/`delete` ciblent par `id`
-
-```ts
-await aura.db.from('posts').insert({ title: 'Hello', published: false })
-await aura.db.from('posts').insert([{ title: 'A' }, { title: 'B' }])
-
-// Pas de .eq(...) : update()/delete() prennent l'id directement en premier argument.
-const postId = 'post-id'
-await aura.db.from('posts').update(postId, { published: true })
-await aura.db.from('posts').delete(postId)
-
-await aura.db.from('posts').upsert({ id: postId, title: 'Updated' }, { onConflict: 'id' })
-```
-
-### SQL brut et schéma
-
-```ts
-// Passthrough direct vers Postgres — PAS en lecture seule (voir Limitations).
-const rows = await aura.db.sql('SELECT count(*) FROM posts WHERE published = $1', [true])
-
-const schema = await aura.db.schema() // schema.data: { tables: SchemaTable[]; functions: SchemaFunction[] } du projet courant
-```
-
-## Fonctions Postgres (rpc)
-
-`aura.db.rpc(fnName, args?, options?)` appelle une fonction Postgres exposée par PostgREST (`POST|GET|HEAD /rpc/{fn}`) et retourne un builder filtrable (mêmes modificateurs que `from()` : `.eq()`, `.select()`, `.single()`, `.order()`, …).
-
-```ts
-// Appel scalaire (POST par défaut, args en body).
-const { data: sum } = await aura.db.rpc('add', { a: 1, b: 2 })
-```
-
-```ts
-// Fonction SETOF : le résultat est filtrable comme une table.
-const { data: thing } = await aura.db
-  .rpc('list_things', {})
-  .eq('id', 2)
-  .select('id,name')
-  .single()
-```
-
-Options (3e argument) :
-
-```ts
-// count: 'exact' | 'planned' | 'estimated' → total exposé dans meta.total.
-const { data, meta } = await aura.db.rpc('list_things', {}, { count: 'exact' })
-console.log(meta?.total)
-
-// get: true → GET (args sérialisés en query string, pas de body).
-await aura.db.rpc('now', undefined, { get: true })
-
-// head: true → HEAD (args en query, aucun corps de réponse — utile avec count).
-await aura.db.rpc('list_things', {}, { head: true, count: 'exact' })
-```
-
-Typage : si `Database['public']['Functions'][fn]` est connu, `args` est typé strictement et le résultat infère `Row`/`Result` à partir de `Returns` (scalaire pour une fonction scalaire, tableau pour un SETOF) — sans double-emballage : `rpc('add', …)` type `number | null`, `rpc('list_things', …)` sans `.select()` type `{ id; name }[] | null`. Une colonne précise après `.select()` sur un SETOF (ex. `.select('id,name').single()` → `{ id: number; name: string } | null`) nécessite que `SetofOptions.to` pointe une **vraie table** du bloc `Tables` du `Database` — ce qui suppose un `Database` écrit à la main. **Généré par [`@aurabase/gen`](../gen) :** seuls les `Args` (et le retour scalaire) sont typés strictement ; `@aurabase/gen` ne résout pas la table réellement ciblée par un `SETOF`, donc `SetofOptions.to` y est un placeholder qui ne matche jamais une table — un SETOF `.select()` retombe alors sur `Record<string, unknown>[]` (voir [limitations de `@aurabase/gen`](../gen/README.md)). Sans `Database` typé (ou fonction absente du bloc `Functions`), `rpc()` reste permissif (`args?: Record<string, unknown>`, résultat `any`) — aucune régression pour les appels non typés.
-
-```ts
-import { createClient } from 'aurabase'
-
-type Database = {
-  public: {
-    Tables: Record<string, never>
-    Views: Record<string, never>
-    Functions: {
-      add: { Args: { a: number; b: number }; Returns: number }
-    }
-    Enums: Record<string, never>
-    CompositeTypes: Record<string, never>
-  }
-}
-
-const aura = createClient<Database>('http://localhost:8080', 'my-project', 'aura_anon_xxx')
-await aura.db.rpc('add', { a: 1, b: 2 }) // args vérifiés à la compilation
-```
-
-## Limitations
-
-- `rpc()` est Postgres-only : non disponible si le projet utilise MongoDB comme moteur (`aura.db.schema()` renvoie alors `functions: []`).
-- `update(id, body)` et `delete(id)` ciblent toujours une ligne par `id` : pas d'équivalent `.update(values).eq('col', v)` filtrant sur un critère arbitraire.
-- Pas de `range()`, `csv()`, `geojson()`, `explain()`, `abortSignal()`, `returns()` (parité postgrest-js partielle).
-- `or()` prend un tableau d'objets `{ column, op, value }`, pas la chaîne PostgREST `"col.eq.val,col2.gt.val2"`.
-- `sql()` n'a aucun filtre applicatif par type d'instruction (SELECT/INSERT/UPDATE/DELETE/DDL s'exécutent tous réellement, dans la limite des GRANTs du rôle Postgres du projet) — à ne pas exposer sans restriction à des clients non fiables.
-- Format de câblage (wire format) propre à Aurabase : non interopérable avec un serveur PostgREST tiers.
-
-## Documentation
-
-Référence complète du SDK (tous les services, types partagés, SSR) : [README racine](../../README.md).

package/packages/db/VENDORED.md

@@ -1,93 +0,0 @@
-# Code vendoré — `@supabase/postgrest-js`
-
-`@aurabase/db` embarque, sous licence MIT, une copie adaptée de la couche
-type-level de [`@supabase/postgrest-js`](https://github.com/supabase/postgrest-js)
-(parseur de `select()` + résolveur de types `GetResult`). Ce document fige la
-provenance et la procédure de resync — introduit par LOT 6 (audit SDK,
-2026-07-12, finding I7 : « vendoré sans provenance »).
-
-## Fichiers vendorés
-
-| Fichier | Rôle |
-|---|---|
-| `src/select-query-parser/parser.ts` | Parseur de la string `select()` en AST (`Ast.Node[]`) |
-| `src/select-query-parser/result.ts` | `GetResult<...>` — résolution du type de retour d'un `select()` (point d'entrée) |
-| `src/select-query-parser/types.ts` | Types utilitaires partagés du parseur/résolveur |
-| `src/select-query-parser/utils.ts` | `ResolveRelationship` et le reste de la logique de résolution des embeds |
-| `src/pgrst-types/feature-flags.ts` | Feature flags par version de PostgREST (`MaxAffectedEnabled`, `SpreadOnManyEnabled`) |
-| `src/pgrst-types/types.ts` | Types PostgREST génériques (`GenericTable`, `TypeScriptTypes`, `PostgreSQLTypes`, ...) |
-| `src/pgrst-types/common/common.ts` | Types partagés supabase-js/postgrest-js (`Fetch`, `ClientServerOptions`, ...) |
-| `src/pgrst-types/common/rpc.ts` | Typage des appels `.rpc()` (`GenericFunction`, matching des `Args`) |
-
-Chaque fichier porte un en-tête `// Vendored from @supabase/postgrest-js (MIT,
-Copyright (c) Supabase).` renvoyant vers ce document. **Ne pas modifier la
-logique de ces fichiers** hors resync délibéré (voir plus bas) — les
-adaptations aurabase (renommages, ajustements d'import) sont volontairement
-minimales pour garder un diff resync-friendly avec l'amont.
-
-## Version d'origine
-
-Vendoré initialement dans le commit `414d9f60` (« feat(db): vendore la couche
-type-level de postgrest-js (MIT) pour l'inférence de select », 2026-07-12).
-**La version exacte / le SHA amont de `@supabase/postgrest-js` au moment du
-vendoring n'a pas été consigné à l'époque — à confirmer et à figer ici au
-prochain resync.** Tant que cette ligne n'est pas mise à jour, considérer la
-provenance comme « non pinnée » : en cas de bug suspecté dans cette couche,
-comparer manuellement avec la version courante de `@supabase/postgrest-js` sur
-npm/GitHub plutôt que de supposer une version précise.
-
-```
-Source amont : @supabase/postgrest-js (https://github.com/supabase/postgrest-js)
-Licence      : MIT (Copyright (c) Supabase)
-SHA / version amont au vendoring : NON CONSIGNÉ — à figer ici au prochain resync
-Vendoré le   : 2026-07-12 (commit 414d9f60)
-```
-
-## `PostgrestVersion` figé à `'12'`
-
-`AuraClientOptionsT` (`src/QueryBuilder.ts`) fixe
-`PostgrestVersion: '12'` de façon codée en dur — le SDK Aurabase ne négocie
-pas de version PostgREST avec le backend. Conséquence directe sur le code
-vendoré : les feature flags `MaxAffectedEnabled` / `SpreadOnManyEnabled`
-(`src/pgrst-types/feature-flags.ts`), conçus en amont pour activer des
-comportements PostgREST 13/14, sont **présents mais structurellement inertes**
-dans aurabase-js (`IsPostgrestVersionGreaterThan12<'12'>` est toujours
-`false`). Ce n'est pas un bug — c'est un vendoring volontairement fidèle à
-l'amont (pas de fork de la logique) doublé d'un pin explicite de version côté
-aurabase. Si le backend `aura-db`/PostgREST venait à monter en version 13+,
-ce pin devra être révisé de concert avec le générateur de schéma (LOT 4) et
-les tests type-level du vendoré (`packages/db/tests/vendored/`).
-
-## Procédure de resync manuelle
-
-Ce vendoring n'est pas automatisé (pas de sous-module, pas de script de sync).
-Pour rapatrier une version plus récente de `@supabase/postgrest-js` :
-
-1. Récupérer la version cible du paquet npm `@supabase/postgrest-js` (choisir
-   un tag/SHA précis — ne jamais resync sur un HEAD flottant).
-2. Comparer fichier par fichier avec la liste ci-dessus (`src/select-query-parser/*`,
-   `src/pgrst-types/*`) — l'amont peut avoir renommé/déplacé des fichiers
-   entre deux versions, vérifier la table de correspondance à cette occasion.
-3. Réappliquer les adaptations aurabase minimales (renommages de types
-   `Aura*` le cas échéant, ajustements d'import relatifs — actuellement
-   aucune divergence de logique volontaire n'est connue ; si une divergence
-   est découverte pendant le resync, la documenter ici avant de l'écraser).
-4. Mettre à jour la ligne « SHA / version amont » de ce document.
-5. Faire tourner :
-   - `pnpm --filter @aurabase/db test` (suite unitaire + `tsc -p tsconfig.test-d.json`)
-   - `pnpm --filter @aurabase/db test tests/scale/scale-compile.test.ts` (garde
-     TS2589 à l'échelle — LOT 6, voir `tests/scale/`)
-   - `pnpm --filter @aurabase/db test tests/vendored/` (régression de forme sur
-     le vendoré — LOT 6, voir `tests/vendored/`)
-6. Si `PostgrestVersion` amont introduit un nouveau feature flag pertinent
-   pour aurabase (ex. passage à PostgREST 13+ côté backend), le câbler
-   explicitement plutôt que de le laisser inerte silencieusement.
-
-## Pourquoi vendorer plutôt que dépendre de `@supabase/postgrest-js`
-
-Décision déjà actée au moment du vendoring (commit `414d9f60`) : le SDK
-Aurabase a son propre `AuraQueryBuilder`/`DatabaseService` (pas le client
-`postgrest-js`), seule la couche de résolution de types (`GetResult` et son
-parseur) est réutilisée. Vendorer évite une dépendance runtime/type sur un
-paquet dont l'API cliente n'est pas utilisée telle quelle, au prix du coût de
-maintenance documenté ci-dessus (resync manuel).