wip:milestone 0 fixes
Some checks failed
CI/CD Pipeline / unit-tests (push) Failing after 1m16s
CI/CD Pipeline / integration-tests (push) Failing after 2m32s
CI/CD Pipeline / lint (push) Successful in 5m22s
CI/CD Pipeline / e2e-tests (push) Has been skipped
CI/CD Pipeline / build (push) Has been skipped

This commit is contained in:
2026-03-15 12:35:42 +02:00
parent 6708cf28a7
commit cffdf8af86
61266 changed files with 4511646 additions and 1938 deletions

52
docs/WASI_DENO.md Normal file
View File

@@ -0,0 +1,52 @@
# Plan: Deno Compatibility for MadBase Edge Functions
## Problem Statement
Currently, MadBase executes Edge Functions as WASM modules via `wasmtime`. Supabase-compatible Edge Functions (like those in `accountaflow`) are written in TypeScript and target a Deno environment. Migrating these requires 1:1 compatibility for the `Deno` namespace, ES modules, and standard web APIs (Fetch, Request, Response).
## Proposed Architecture
### 1. Dual-Runtime Strategy
Extend the `functions` crate to support two runtimes:
- **WasmRuntime**: Existing `wasmtime` based executor for compiled modules.
- **DenoRuntime**: A new V8-based executor utilizing `deno_core` and `deno_runtime`.
### 2. Runtime Detection
The gateway should detect the function type:
- **DenoRuntime (V8)**: Files ending in `.ts` or `.js`. Recommended for standard Edge Functions due to JIT-optimized performance.
- **WasmRuntime (Wasmtime)**: Native WASM binaries (Rust, Go, C++). Best for specialized, high-performance logic or pre-compiled modules.
## Implementation Steps
### Phase 1: Core Integration
- Add `deno_core` and `deno_runtime` dependencies to `madbase/functions/Cargo.toml`.
- Create `functions/src/deno_runtime.rs`.
- Implement `execute_script(code: String, payload: Value)` using `JsRuntime`.
### Phase 2: Supabase Environment Compatibility
- **Process Environment**: Inject `SUPABASE_URL`, `SUPABASE_ANON_KEY`, and `SUPABASE_SERVICE_ROLE_KEY`.
- **Global Objects**: Implement a shim for `Deno.serve` to capture the incoming request and route it to the script's handler.
- **Header Parsing**: Ensure standard headers (`apikey`, `Authorization`) are passed through.
### Phase 3: Module Resolution
- Implement a `ModuleLoader` that handles imports from `https://esm.sh/`.
- Support local imports from a shared functions directory (like `_shared`).
## API Changes
### Gateway
Modify `POST /functions/v1` to accept `type: "typescript" | "wasm"`. Default to "typescript" for source code.
### Deployment Table
Update the `functions` table schema in the control plane to store the runtime type.
## Verification Plan
### Automated Tests
1. **Hello World Test**: Deploy a simple `.ts` function and verify the output.
2. **Supabase Client Test**: Deploy a function that imports `@supabase/supabase-js` from `esm.sh` and queries the MadBase Data API.
3. **Environment Variable Test**: Verify `Deno.env.get` returns expected MadBase configuration.
### Manual Verification
1. Attempt to deploy the `invite-staff` function from `accountaflow` directly to MadBase.
2. Verify cross-organization invitation logic works.