# EdgeChains keeps prompts in jsonnet and compiles them into a WebAssembly module

> A generative AI library that treats prompts and chains as configuration files rather than string literals, built on Hono and jsonnet, with the execution path running through a Rust engine compiled to wasm32-wasip1. The default branch is named ts, the newest npm release is twenty months old, and 296 open issues sit on 428 stars.

**arakoodev/EdgeChains** — EdgeChains.js is Full-Stack GenAI library. Front-end, backend, apis, prompt management, distributed computing. All core prompts & chains are managed declaratively in jsonnet (and not hidden in classes)

- Repository: https://github.com/arakoodev/EdgeChains
- Website: https://www.arakoo.ai/
- Stars: 428 · Forks: 244
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/arakoodev-edgechains

## Prompt drift is the argument, and versioned jsonnet is the answer

The project starts from a claim about maintenance rather than about generation. Prompts change over time, which the project calls prompt drift, and published research shows how a model's behaviour changes under a prompt that has not moved. If your prompts are buried under layers of library abstraction, versioning against that drift is impossible and your production code rots even when you changed nothing.

The mechanism is that prompts are written in jsonnet, so they are versionable and diffable like any other config. jsonnet is Google's language from Borg configuration management, and the project is explicit that it does not invent its own JSON flavour or DSL and does not add compilation steps for its own syntax.

The consequence is architectural. A prompt is a file, so it can live in S3 or behind an API, and a chain can be tested by pointing the same harness at a different jsonnet version rather than by patching a string in a function call.

## The default branch is named ts and the newest npm release is from 2024

The repository's default branch is ts, not main or master. Anything you clone by default lands on that branch, and any tool that assumes a main branch will find nothing.

The release history tells a harder story. The three most recent npm releases are 0.30.3 from 2024-12-26, 0.30.2 from 2024-12-21 and 0.30.1 from 2024-11-05, all published within two months of each other. The last commit on ts arrived on 2026-10-01, roughly twenty months after the last release.

So the published packages and the branch you clone are two different states of the same project, and the gap is large enough that the examples in the documentation may not correspond to what npm hands you. 428 stars, 243 forks and 296 open issues point the same direction: heavy trial use, with a support queue behind it.

## The build compiles Rust to wasm32-wasip1 and wraps it with javy

The execution path is not a JavaScript runtime. A Cargo workspace spans four members, arakoo-core, cli, serve and the JS/jsonnet crate, and the engine is compiled to a WebAssembly target:

```
build-engine: build-shims
	@echo "Building arakoo engine"
	@cargo build -p arakoo-js-engine --target=wasm32-wasip1 -r

build-cli: build-engine
	@echo "Building javy cli"
	@CARGO_PROFILE_RELEASE_LTO=off cargo build -p cli -r
```

The compilation step runs the javy CLI to turn a JavaScript bundle into a module, and the serve step then runs that module directly:

```
compile: build-example
	./target/release/javy compile JS/wasm/examples/ec-wasmjs-hono/bin/app.js

serve:
	./target/release/arakoo index.wasm
```

So a running system is a .wasm file plus a loader. The dependencies make the intent plain: wizer for pre-initialization, wasmtime with async support, wasmtime-wasi, and javy as the JS-to-wasm bridge. Release builds turn on link-time optimization and optimize for size.

## The chat-with-pdf setup has you paste SQL that the documentation cuts off mid-statement

The worked example runs on Supabase with a pgvector column, and the schema is a 1536-dimensional embedding column plus a match function. The instructions are step by step: create a query in the SQL editor, paste it, run it, expect a success message in the Result tab.

The pasted block ends in the middle of the order clause, at order by documents.embedding <=> query_em. So the function that every retrieval call depends on is shown truncated, and a reader following the steps literally pastes invalid SQL.

The rest of the setup is three configuration values in secrets.jsonnet, with locals bound to a Supabase key, an OpenAI key and a Supabase URL, then an object mapping them to snake_case keys. The three lines after the schema paste the start step and a GET request at localhost:3000/chatWithpdf with a question parameter, and a stray unclosed fence swallows the closing instruction into the code block.

## Automatic parallelism comes from the runtime, not from the library

The feature list claims chains and chain-of-thought tasks are parallelized automatically across CPUs, GPUs and TPUs using the WebAssembly runtime, and that the system retries with backoff when individual requests fail.

Neither claim is implemented in the JavaScript you would install. Both follow from the architecture: the work is expressed as a compiled module rather than as interleaved promises, and the runtime underneath it supports the concurrency. The chain does not know about it.

That cuts both ways. You get parallelism without writing a scheduler, and you also lose the ability to inspect or patch scheduling behaviour from your own code, because there is no layer of your own between the chain and the runtime.

## The root package.json has no name, no version and no scripts

The file at the repository root is not a publishable package definition. It has a dependencies block and a devDependencies block and nothing else:

```json
{
  "dependencies": {
    "@microsoft/eslint-formatter-sarif": "^3.1.0",
    "@playwright/test": "^1.46.0",
    "@typescript-eslint/eslint-plugin": "^8.71.0",
    "axios": "^1.7.3",
    "eslint": "^8.57.1",
    "express": "^4.18.2",
    "prettier": "^3.9.9"
  },
  "devDependencies": {
    "@types/express": "^4.17.21",
    "@types/jest": "^29.5.11"
  }
}
```

No name, no version, no scripts, no main, no license field. The packages that carry versions are built separately, and the Makefile shows where: build-edgechains copies the README into a subdirectory, installs, builds and versions, then deletes the src directory, and build-jsonnet does the same for the jsonnet package with a TAG variable.

So npm run start in the example is a script inside the example, not in this file. Anyone expecting to install the root and run it will find neither a package identity nor an entry point.

## AGPL-3.0 and a prompt-driven cost argument define the audience

The licence is AGPL-3.0, which is the strongest copyleft of the common ones and the one that matters most if you plan to serve the result over a network.

The audience argument in the documentation is narrower than that. It argues that prompt techniques transfer badly between models, so a chain written for one model has to be rewritten for another, which makes prompts explode in number and hard to version. It also argues on cost: chain-of-thought style prompts consume at least three times as many output tokens as a normal prompt, so a framework needs fine-grained token tracking built in or you cannot tell a good prompt from an expensive one.

That is the pitch for someone running many chains across several models in production, which is also who the AGPL suits least. A team shipping a hosted product built on this has to read the licence terms against their own distribution model before anything else.

## Conclusion

Use it if prompt drift is a real problem for you and you want a diff on a prompt the way you would diff a config file, since that argument is the project's whole case and the repository backs it. Do not adopt it expecting an npm install to give you a working runtime, because the published packages and the default branch tell different stories and the build path goes through Rust and javy. Before you commit, check the default branch is named ts rather than main, read the chat-with-pdf example end to end since its SQL is truncated in the documentation, and decide whether AGPL-3.0 suits what you intend to build.

## FAQ

### Why does EdgeChains write prompts in jsonnet?

So prompts become versionable and diffable files rather than strings hidden inside library layers. jsonnet is Google's configuration language from Borg, and prompts can then live in S3 or behind an API and be tested by pointing a harness at a different version.

### What is the default branch of the EdgeChains repository?

It is named ts. The most recent npm releases are 0.30.3 from 2024-12-26, 0.30.2 from 2024-12-21 and 0.30.1 from 2024-11-05, while the last commit on that branch is from 2026-10-01.

### How is the EdgeChains runtime built?

A Cargo workspace builds an engine crate for the wasm32-wasip1 target and a cli crate, with LTO turned off for the CLI build. javy compiles a JavaScript bundle into a module, and the serve target runs the resulting index.wasm through the arakoo binary.

### What do I need to run the EdgeChains chat-with-pdf example?

A PostgreSQL vector database at Supabase with a documents table and a match_documents function, plus three values in secrets.jsonnet for the Supabase key, the Supabase URL and the OpenAI key. The example then starts with npm run start and queries localhost:3000/chatWithpdf.

### Can I npm install the EdgeChains repository root?

No. The root package.json carries only dependencies and devDependencies, with no name, version, main or scripts. The versioned packages are built by separate Makefile targets using a TAG variable, and each build step removes the src directory afterwards.

## Sources

- [arakoodev/EdgeChains on GitHub](https://github.com/arakoodev/EdgeChains)
- [License: AGPL-3.0](https://github.com/arakoodev/EdgeChains/blob/ts/LICENSE)
- [Project website](https://www.arakoo.ai/)
- [README](https://github.com/arakoodev/EdgeChains/blob/ts/README.md)
- [Releases](https://github.com/arakoodev/EdgeChains/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arakoodev-edgechains