mirror of
https://github.com/run-llama/LlamaIndexTS.git
synced 2026-07-03 19:19:08 -04:00
Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 62eb1e5f4f |
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"@llamaindex/openai": patch
|
||||
---
|
||||
|
||||
Update o4-mini to accept reasoning parameters and exclude temperature
|
||||
@@ -8,11 +8,6 @@ on:
|
||||
branches:
|
||||
- main
|
||||
|
||||
env:
|
||||
TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
|
||||
TURBO_TEAM: ${{ vars.TURBO_TEAM }}
|
||||
TURBO_REMOTE_ONLY: true
|
||||
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
@@ -1,11 +1,6 @@
|
||||
name: Publish Preview
|
||||
on: [pull_request]
|
||||
|
||||
env:
|
||||
TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
|
||||
TURBO_TEAM: ${{ vars.TURBO_TEAM }}
|
||||
TURBO_REMOTE_ONLY: true
|
||||
|
||||
jobs:
|
||||
pre_release:
|
||||
name: Pre Release
|
||||
|
||||
@@ -23,7 +23,7 @@ jobs:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
node-version: [20.x, 22.x, 23.x]
|
||||
node-version: [18.x, 20.x, 22.x, 23.x]
|
||||
name: E2E on Node.js ${{ matrix.node-version }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
@@ -53,7 +53,7 @@ jobs:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
node-version: [20.x, 22.x, 23.x]
|
||||
node-version: [18.x, 20.x, 22.x, 23.x]
|
||||
name: Test on Node.js ${{ matrix.node-version }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
@@ -87,30 +87,6 @@ jobs:
|
||||
run: pnpm run type-check
|
||||
- name: Run Circular Dependency Check
|
||||
run: pnpm run circular-check
|
||||
e2e-npm:
|
||||
runs-on: ubuntu-latest
|
||||
name: Test using packages with npm
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: pnpm/action-setup@v4
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version-file: ".nvmrc"
|
||||
- name: Install dependencies
|
||||
run: pnpm install
|
||||
- name: Build packages
|
||||
run: pnpm run build
|
||||
- name: Pack packages
|
||||
run: |
|
||||
pnpm pack --pack-destination ${{ runner.temp }} -C packages/llamaindex
|
||||
pnpm pack --pack-destination ${{ runner.temp }} -C packages/workflow
|
||||
- name: Install packed packages
|
||||
run: npm add ${{ runner.temp }}/*.tgz
|
||||
working-directory: e2e/npm
|
||||
- name: Run tests
|
||||
run: npm test
|
||||
working-directory: e2e/npm
|
||||
e2e-llamaindex-examples:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
|
||||
@@ -7,4 +7,3 @@ dist/
|
||||
.source/
|
||||
# prttier doesn't support mdx3 we are using
|
||||
*.mdx
|
||||
packages/server/server/
|
||||
@@ -1,92 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## Development Commands
|
||||
|
||||
This project uses pnpm as the package manager and Turbo for build orchestration:
|
||||
|
||||
- `pnpm install` - Install all dependencies
|
||||
- `pnpm build` - Build all packages using Turbo
|
||||
- `pnpm dev` - Start development mode for all packages
|
||||
- `pnpm test` - Run all unit tests
|
||||
- `pnpm e2e` - Run end-to-end tests
|
||||
- `pnpm lint` - Run ESLint across all packages
|
||||
- `pnpm type-check` - Run TypeScript type checking across workspace
|
||||
- `pnpm format` - Check code formatting with Prettier
|
||||
- `pnpm format:write` - Auto-fix formatting issues
|
||||
- `pnpm circular-check` - Check for circular dependencies using madge
|
||||
|
||||
For individual package development:
|
||||
|
||||
- `turbo run build --filter="@llamaindex/core"` - Build specific package
|
||||
- `turbo run test --filter="@llamaindex/core"` - Test specific package
|
||||
- Navigate to specific package directory and run `pnpm test` for focused testing
|
||||
- `pnpm clean` - Remove all build artifacts and node_modules across workspace
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
LlamaIndex.TS is a TypeScript data framework for LLM applications organized as a pnpm monorepo with multiple runtime environment support (Node.js, Deno, Bun, Vercel Edge, Cloudflare Workers).
|
||||
|
||||
### Package Structure
|
||||
|
||||
**Core Packages:**
|
||||
|
||||
- `packages/core/` - Abstract base classes and interfaces for all runtime environments
|
||||
- `packages/llamaindex/` - Main package that aggregates core functionality
|
||||
- `packages/env/` - Environment-specific compatibility layers for different JS runtimes
|
||||
|
||||
**Provider Packages (`packages/providers/`):**
|
||||
|
||||
- LLM providers: `openai/`, `anthropic/`, `ollama/`, `google/`, `groq/`, etc.
|
||||
- Vector stores: `storage/pinecone/`, `storage/chroma/`, `storage/qdrant/`, etc.
|
||||
- Embeddings: Various embedding providers integrated within LLM packages
|
||||
- Readers: `assemblyai/`, `discord/`, `notion/` for data ingestion
|
||||
|
||||
**Specialized Packages:**
|
||||
|
||||
- `packages/cloud/` - LlamaCloud integration for managed services
|
||||
- `packages/tools/` - Function calling tools and utilities
|
||||
- `packages/workflow/` - Agent workflow orchestration
|
||||
- `packages/readers/` - File format readers (PDF, DOCX, etc.)
|
||||
|
||||
### Key Architectural Patterns
|
||||
|
||||
**Runtime Abstraction:** Core functionality is runtime-agnostic, with environment-specific implementations in separate entry points (`index.ts`, `index.edge.ts`, `index.workerd.ts`).
|
||||
|
||||
**Provider Pattern:** LLMs, embeddings, and vector stores implement common interfaces from `@llamaindex/core`, allowing easy swapping between providers.
|
||||
|
||||
**Modular Design:** Each provider is a separate package to minimize bundle size - users install only what they need.
|
||||
|
||||
**Data Flow:** Document → NodeParser → Embedding → VectorStore → Retriever → QueryEngine → Response
|
||||
|
||||
### Core Components
|
||||
|
||||
- **Agents and Workflows:** Abstractions for building agentic workflows and agents in `packages/workflow`
|
||||
- **Chat Engines:** Conversational interfaces in `core/chat-engine/`
|
||||
- **Query Engines:** Document querying with retrieval in `core/query-engine/`
|
||||
- **Indices:** VectorStoreIndex, SummaryIndex, KeywordTable in `llamaindex/indices/`
|
||||
- **Node Parsers:** Text splitting and chunking in `core/node-parser/`
|
||||
- **Ingestion Pipeline:** Document processing workflows in `llamaindex/ingestion/`
|
||||
- **Storage:** Chat stores, document stores, index stores, and KV stores in `core/storage/`
|
||||
|
||||
### Deprecated Components
|
||||
|
||||
- **Agents:** ReAct and function calling agents in `core/agent/` and `llamaindex/agent/`
|
||||
|
||||
### Testing Structure
|
||||
|
||||
- Unit tests in each package's `tests/` directory
|
||||
- E2E tests in `e2e/` directory with runtime-specific examples
|
||||
- Tests depend on build artifacts, so always run `pnpm build` before testing
|
||||
|
||||
### Multi-Runtime Support
|
||||
|
||||
The codebase supports multiple JavaScript runtimes through conditional exports and separate entry points. When making changes, consider compatibility across Node.js, Deno, Bun, and edge runtimes.
|
||||
|
||||
### Development Notes
|
||||
|
||||
- The project uses Husky for git hooks with lint-staged for pre-commit formatting and linting
|
||||
- All packages use bunchee for building with dual CJS/ESM support
|
||||
- Core package exports are organized as sub-modules (e.g., `@llamaindex/core/llms`, `@llamaindex/core/embeddings`)
|
||||
- Always run `pnpm build` before running tests, as tests depend on build artifacts
|
||||
@@ -7,10 +7,9 @@
|
||||
</h3>
|
||||
|
||||
[](https://www.npmjs.com/package/llamaindex)
|
||||
[](https://github.com/run-llama/LlamaIndexTS/blob/main/LICENSE)
|
||||
[](https://www.npmjs.com/package/llamaindex)
|
||||
[](https://www.npmjs.com/package/llamaindex)
|
||||
[](https://discord.com/invite/eN6D2HQ4aX)
|
||||
[](https://x.com/llama_index)
|
||||
|
||||
Use your own data with large language models (LLMs, OpenAI ChatGPT and others) in JS runtime environments with TypeScript support.
|
||||
|
||||
@@ -64,7 +63,7 @@ yarn add llamaindex
|
||||
|
||||
### Setup in Node.js, Deno, Bun, TypeScript...?
|
||||
|
||||
See our official document: https://ts.llamaindex.ai/docs/llamaindex/getting_started
|
||||
See our official document: <https://ts.llamaindex.ai/docs/llamaindex/getting_started/>
|
||||
|
||||
### Adding provider packages
|
||||
|
||||
@@ -84,7 +83,19 @@ Check out our NextJS playground at https://llama-playground.vercel.app/. The sou
|
||||
|
||||
## Core concepts for getting started:
|
||||
|
||||
See our documentation: https://ts.llamaindex.ai/docs/llamaindex/getting_started/concepts
|
||||
- [Document](/packages/llamaindex/src/Node.ts): A document represents a text file, PDF file or other contiguous piece of data.
|
||||
|
||||
- [Node](/packages/llamaindex/src/Node.ts): The basic data building block. Most commonly, these are parts of the document split into manageable pieces that are small enough to be fed into an embedding model and LLM.
|
||||
|
||||
- [Embedding](/packages/llamaindex/src/embeddings/OpenAIEmbedding.ts): Embeddings are sets of floating point numbers which represent the data in a Node. By comparing the similarity of embeddings, we can derive an understanding of the similarity of two pieces of data. One use case is to compare the embedding of a question with the embeddings of our Nodes to see which Nodes may contain the data needed to answer that question. Because the default service context is OpenAI, the default embedding is `OpenAIEmbedding`. If using different models, say through Ollama, use this [Embedding](/packages/llamaindex/src/embeddings/OllamaEmbedding.ts) (see all [here](/packages/llamaindex/src/embeddings)).
|
||||
|
||||
- [Indices](/packages/llamaindex/src/indices/): Indices store the Nodes and the embeddings of those nodes. QueryEngines retrieve Nodes from these Indices using embedding similarity.
|
||||
|
||||
- [QueryEngine](/packages/llamaindex/src/engines/query/RetrieverQueryEngine.ts): Query engines are what generate the query you put in and give you back the result. Query engines generally combine a pre-built prompt with selected Nodes from your Index to give the LLM the context it needs to answer your query. To build a query engine from your Index (recommended), use the [`asQueryEngine`](/packages/llamaindex/src/indices/BaseIndex.ts) method on your Index. See all query engines [here](/packages/llamaindex/src/engines/query).
|
||||
|
||||
- [ChatEngine](/packages/llamaindex/src/engines/chat/SimpleChatEngine.ts): A ChatEngine helps you build a chatbot that will interact with your Indices. See all chat engines [here](/packages/llamaindex/src/engines/chat).
|
||||
|
||||
- [SimplePrompt](/packages/llamaindex/src/Prompt.ts): A simple standardized function call definition that takes in inputs and formats them in a template literal. SimplePrompts can be specialized using currying and combined using other SimplePrompt functions.
|
||||
|
||||
## Contributing:
|
||||
|
||||
|
||||
@@ -1,148 +1,5 @@
|
||||
# @llamaindex/doc
|
||||
|
||||
## 0.2.24
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [766054b]
|
||||
- Updated dependencies [71598f8]
|
||||
- @llamaindex/workflow@1.1.6
|
||||
- @llamaindex/core@0.6.9
|
||||
- llamaindex@0.11.5
|
||||
- @llamaindex/cloud@4.0.13
|
||||
- @llamaindex/node-parser@2.0.9
|
||||
- @llamaindex/openai@0.4.3
|
||||
- @llamaindex/readers@3.1.7
|
||||
|
||||
## 0.2.23
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [c927457]
|
||||
- @llamaindex/openai@0.4.2
|
||||
- @llamaindex/core@0.6.8
|
||||
- @llamaindex/cloud@4.0.12
|
||||
- llamaindex@0.11.4
|
||||
- @llamaindex/node-parser@2.0.8
|
||||
- @llamaindex/readers@3.1.6
|
||||
- @llamaindex/workflow@1.1.5
|
||||
|
||||
## 0.2.22
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [76ff23d]
|
||||
- @llamaindex/cloud@4.0.11
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.2.21
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [59601dd]
|
||||
- @llamaindex/openai@0.4.1
|
||||
- @llamaindex/core@0.6.7
|
||||
- @llamaindex/cloud@4.0.10
|
||||
- llamaindex@0.11.2
|
||||
- @llamaindex/node-parser@2.0.7
|
||||
- @llamaindex/readers@3.1.5
|
||||
- @llamaindex/workflow@1.1.4
|
||||
|
||||
## 0.2.20
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3703f90]
|
||||
- @llamaindex/cloud@4.0.9
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.2.19
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [680b529]
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- Updated dependencies [3e66ddc]
|
||||
- @llamaindex/workflow@1.1.3
|
||||
- @llamaindex/core@0.6.6
|
||||
- llamaindex@0.11.0
|
||||
- @llamaindex/openai@0.4.0
|
||||
- @llamaindex/cloud@4.0.8
|
||||
- @llamaindex/node-parser@2.0.6
|
||||
- @llamaindex/readers@3.1.4
|
||||
|
||||
## 0.2.18
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- d671ed6: Add functionality for search params when querying Qdrant vector store.
|
||||
- Updated dependencies [76c9a80]
|
||||
- Updated dependencies [168d11f]
|
||||
- Updated dependencies [d671ed6]
|
||||
- Updated dependencies [40f5f41]
|
||||
- @llamaindex/openai@0.3.7
|
||||
- @llamaindex/workflow@1.1.2
|
||||
- @llamaindex/core@0.6.5
|
||||
- @llamaindex/cloud@4.0.7
|
||||
- llamaindex@0.10.6
|
||||
- @llamaindex/node-parser@2.0.5
|
||||
- @llamaindex/readers@3.1.3
|
||||
|
||||
## 0.2.17
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [9b2e25a]
|
||||
- @llamaindex/openai@0.3.6
|
||||
- @llamaindex/core@0.6.4
|
||||
- llamaindex@0.10.5
|
||||
- @llamaindex/cloud@4.0.6
|
||||
- @llamaindex/node-parser@2.0.4
|
||||
- @llamaindex/readers@3.1.2
|
||||
- @llamaindex/workflow@1.1.1
|
||||
|
||||
## 0.2.16
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [7e8e454]
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [bc53342]
|
||||
- Updated dependencies [41953a3]
|
||||
- @llamaindex/workflow@1.1.0
|
||||
- @llamaindex/cloud@4.0.5
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.2.15
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- @llamaindex/core@0.6.3
|
||||
- llamaindex@0.10.3
|
||||
- @llamaindex/openai@0.3.5
|
||||
- @llamaindex/cloud@4.0.4
|
||||
- @llamaindex/node-parser@2.0.3
|
||||
- @llamaindex/readers@3.1.1
|
||||
- @llamaindex/workflow@1.0.4
|
||||
|
||||
## 0.2.14
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [1e59695]
|
||||
- @llamaindex/readers@3.1.0
|
||||
|
||||
## 0.2.13
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [e5c3f95]
|
||||
- @llamaindex/openai@0.3.4
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.2.12
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,143 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaIndex.TS documentation site.
|
||||
|
||||
## Application Overview
|
||||
|
||||
This is a Next.js documentation site (`@llamaindex/doc`) that serves as the official documentation for LlamaIndex.TS. It's built using Fumadocs, a modern documentation framework, and includes interactive features, API documentation generation, and AI-powered chat functionality.
|
||||
|
||||
## Development Commands
|
||||
|
||||
From this directory (`apps/next/`):
|
||||
|
||||
- `pnpm dev` - Start development server with Turbo
|
||||
- `pnpm build` - Build the documentation site (includes `prebuild` step)
|
||||
- `pnpm start` - Start production server
|
||||
- `pnpm build:docs` - Generate API documentation from TypeScript source
|
||||
- `pnpm validate-links` - Validate all internal and external links
|
||||
|
||||
Key build process:
|
||||
|
||||
1. `prebuild` runs `build:docs` to generate API documentation using TypeDoc
|
||||
2. `build` runs Next.js build process
|
||||
3. `postbuild` runs post-processing scripts and link validation
|
||||
|
||||
## Architecture
|
||||
|
||||
### Framework Stack
|
||||
|
||||
- **Next.js 15.3** - React framework with App Router
|
||||
- **Fumadocs** - Documentation framework with MDX support
|
||||
- **React Server Components** - AI chat functionality with server actions
|
||||
- **Tailwind CSS** - Styling with custom design system
|
||||
- **TypeScript** - Full type safety
|
||||
|
||||
### Key Dependencies
|
||||
|
||||
- **Fumadocs ecosystem**: `fumadocs-ui`, `fumadocs-mdx`, `fumadocs-core`, `fumadocs-openapi`
|
||||
- **AI features**: `ai` package for React Server Components chat
|
||||
- **Code features**: Monaco Editor, Shiki syntax highlighting, Twoslash TypeScript integration
|
||||
- **UI components**: Radix UI primitives, Framer Motion animations
|
||||
- **Content processing**: MDX, remark/rehype plugins, TypeDoc for API generation
|
||||
|
||||
### Directory Structure
|
||||
|
||||
**Content Management:**
|
||||
|
||||
- `src/content/docs/` - MDX documentation files organized by topic
|
||||
- `src/content/docs/api/` - Auto-generated API documentation from TypeScript
|
||||
- `scripts/` - Build-time documentation generation and validation
|
||||
|
||||
**Application Code:**
|
||||
|
||||
- `src/app/` - Next.js App Router pages and API routes
|
||||
- `src/components/` - Reusable React components including UI library
|
||||
- `src/lib/` - Utilities, constants, and configuration
|
||||
|
||||
**Configuration:**
|
||||
|
||||
- `source.config.ts` - Fumadocs MDX configuration with plugins
|
||||
- `next.config.mjs` - Next.js configuration with MDX integration
|
||||
- `tailwind.config.mjs` - Tailwind CSS customization
|
||||
|
||||
### Key Features
|
||||
|
||||
**Documentation Features:**
|
||||
|
||||
- MDX-based content with TypeScript code highlighting
|
||||
- Auto-generated API documentation from TypeScript source
|
||||
- Interactive code examples with Monaco Editor
|
||||
- Math equation support with KaTeX
|
||||
- Link validation and build-time checks
|
||||
|
||||
**Interactive Features:**
|
||||
|
||||
- AI-powered chat interface using React Server Components
|
||||
- Code demos with live TypeScript execution
|
||||
- Interactive UI components and animations
|
||||
- Search functionality across all documentation
|
||||
|
||||
**Build Process:**
|
||||
|
||||
- TypeDoc generates API documentation from workspace packages
|
||||
- Custom scripts transform and validate generated content
|
||||
- Link checking ensures all internal/external links work
|
||||
- Static site generation with 10-minute timeout for large documentation set
|
||||
|
||||
### Configuration Files
|
||||
|
||||
**source.config.ts**: Defines MDX processing pipeline with:
|
||||
|
||||
- Code highlighting themes (Catppuccin)
|
||||
- Twoslash TypeScript integration
|
||||
- Remark/rehype plugins for enhanced Markdown
|
||||
- Content directories including external docs
|
||||
|
||||
**next.config.mjs**: Next.js configuration with:
|
||||
|
||||
- Extended static generation timeout (10 minutes)
|
||||
- Monaco Editor transpilation
|
||||
- Server external packages for build optimization
|
||||
- Webpack/Turbopack aliases for browser compatibility
|
||||
|
||||
### Content Organization
|
||||
|
||||
**Documentation Structure:**
|
||||
|
||||
- `/docs/llamaindex/` - Core LlamaIndex.TS documentation
|
||||
- `/docs/cloud/` - LlamaCloud integration guides
|
||||
- `/docs/api/` - Auto-generated TypeScript API reference
|
||||
|
||||
**Content Sources:**
|
||||
|
||||
- Local MDX files in `src/content/docs/`
|
||||
- External docs from `@llama-flow/docs` package
|
||||
- Generated API docs from TypeScript source
|
||||
|
||||
### Development Notes
|
||||
|
||||
- Documentation content is sourced from multiple locations including external packages
|
||||
- API documentation is regenerated on each build from TypeScript source
|
||||
- The site uses advanced MDX features including custom transformers and plugins
|
||||
- Build process includes comprehensive link validation
|
||||
- Large memory allocation needed for TypeDoc generation (`--max-old-space-size=8192`)
|
||||
- Chat functionality uses React Server Components with streaming responses
|
||||
|
||||
### AI Chat Integration
|
||||
|
||||
The documentation includes an AI chat feature that:
|
||||
|
||||
- Uses React Server Components for server-side AI processing
|
||||
- Integrates with LlamaIndex.TS packages for demonstrations
|
||||
- Provides interactive examples and code generation
|
||||
- Streams responses for better user experience
|
||||
|
||||
### Content Authoring
|
||||
|
||||
When adding new documentation:
|
||||
|
||||
- Create MDX files in appropriate `src/content/docs/` subdirectories
|
||||
- Follow existing content structure and frontmatter conventions
|
||||
- Use Fumadocs MDX features like code blocks, callouts, and tabs
|
||||
- API documentation is auto-generated - edit TypeScript source comments instead
|
||||
- Run `pnpm validate-links` to check all links before publishing
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@llamaindex/doc",
|
||||
"version": "0.2.24",
|
||||
"version": "0.2.12",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"postinstall": "fumadocs-mdx",
|
||||
@@ -15,8 +15,8 @@
|
||||
"dependencies": {
|
||||
"@huggingface/transformers": "^3.5.0",
|
||||
"@icons-pack/react-simple-icons": "^10.1.0",
|
||||
"@llama-flow/docs": "0.0.8",
|
||||
"@llamaindex/chat-ui-docs": "0.0.3",
|
||||
"@llama-flow/docs": "0.0.3",
|
||||
"@llamaindex/chat-ui": "0.2.0",
|
||||
"@llamaindex/cloud": "workspace:*",
|
||||
"@llamaindex/core": "workspace:*",
|
||||
"@llamaindex/node-parser": "workspace:*",
|
||||
@@ -90,9 +90,9 @@
|
||||
"remark-stringify": "^11.0.0",
|
||||
"tailwindcss": "^4.0.9",
|
||||
"tsx": "^4.19.3",
|
||||
"typedoc": "0.28.3",
|
||||
"typedoc": "0.28.2",
|
||||
"typedoc-plugin-markdown": "^4.6.2",
|
||||
"typedoc-plugin-merge-modules": " ^7.0.0",
|
||||
"typedoc-plugin-merge-modules": "^7.0.0",
|
||||
"typescript": "^5.7.3"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
import { generateFiles as openapiGenerateFiles } from "fumadocs-openapi";
|
||||
import {
|
||||
createGenerator,
|
||||
generateFiles as typescriptGenerateFiles,
|
||||
@@ -13,12 +14,18 @@ const apiRefOut = "./src/content/docs/api";
|
||||
// clean generated files
|
||||
rimrafSync(out, {
|
||||
filter(v) {
|
||||
return !v.endsWith("index.md") && !v.endsWith("meta.json");
|
||||
return !v.endsWith("index.mdx") && !v.endsWith("meta.json");
|
||||
},
|
||||
});
|
||||
|
||||
void openapiGenerateFiles({
|
||||
input: ["../../packages/cloud/openapi.json"],
|
||||
output: "./src/content/docs/cloud/api",
|
||||
groupBy: "tag",
|
||||
});
|
||||
|
||||
void typescriptGenerateFiles(generator, {
|
||||
input: ["./src/content/docs/api/**/*.md"],
|
||||
input: ["./src/content/docs/api/**/*.mdx"],
|
||||
output: (file) => path.resolve(path.dirname(file), path.basename(file)),
|
||||
transformOutput,
|
||||
});
|
||||
@@ -27,22 +34,19 @@ function transformOutput(filePath: string, content: string) {
|
||||
const fileName = path.basename(filePath);
|
||||
let title = fileName.split(".")[0];
|
||||
if (title === "index") title = "LlamaIndex API Reference";
|
||||
return `---\ntitle: ${title}\n---\n\n${transformAbsoluteUrl(
|
||||
content.replace(/(?<!\\)\{([^}]+)(?<!\\)}/g, "\\{$1\\}"),
|
||||
filePath,
|
||||
)}`;
|
||||
return `---\ntitle: ${title}\n---\n\n${transformAbsoluteUrl(content, filePath)}`;
|
||||
}
|
||||
|
||||
/**
|
||||
* Transforms the content by converting relative MD links to absolute docs API links
|
||||
* Example: [text](../type-aliases/TaskHandler.md) -> [text](/docs/api/type-aliases/TaskHandler)
|
||||
* [text](BaseChatEngine.md) -> [text](/docs/api/classes/BaseChatEngine)
|
||||
* [text](BaseVectorStore.md#constructors) -> [text](/docs/api/classes/BaseVectorStore#constructors)
|
||||
* [text](TaskStep.md) -> [text](/docs/api/type-aliases/TaskStep)
|
||||
* Transforms the content by converting relative MDX links to absolute docs API links
|
||||
* Example: [text](../type-aliases/TaskHandler.mdx) -> [text](/docs/api/type-aliases/TaskHandler)
|
||||
* [text](BaseChatEngine.mdx) -> [text](/docs/api/classes/BaseChatEngine)
|
||||
* [text](BaseVectorStore.mdx#constructors) -> [text](/docs/api/classes/BaseVectorStore#constructors)
|
||||
* [text](TaskStep.mdx) -> [text](/docs/api/type-aliases/TaskStep)
|
||||
*/
|
||||
function transformAbsoluteUrl(content: string, filePath: string) {
|
||||
const group = path.dirname(filePath).split(path.sep).pop();
|
||||
return content.replace(/\]\(([^)]+)\.md([^)]*)\)/g, (_, slug, anchor) => {
|
||||
return content.replace(/\]\(([^)]+)\.mdx([^)]*)\)/g, (_, slug, anchor) => {
|
||||
const slugParts = slug.split("/");
|
||||
const fileName = slugParts[slugParts.length - 1];
|
||||
const fileGroup = slugParts[slugParts.length - 2] ?? group;
|
||||
|
||||
@@ -4,6 +4,7 @@ import matter from "gray-matter";
|
||||
import path from "path";
|
||||
|
||||
const CONTENT_DIR = path.join(process.cwd(), "src/content/docs");
|
||||
const BUILD_DIR = path.join(process.cwd(), ".next");
|
||||
|
||||
// Regular expression to find internal links
|
||||
// This captures Markdown links [text](/docs/path) and href attributes href="/docs/path"
|
||||
@@ -13,8 +14,6 @@ const INTERNAL_LINK_REGEX = /(?:(?:\]\(|\bhref=["'])\/docs\/([^")]+))/g;
|
||||
// This captures relative links like [text](./path) or 
|
||||
const RELATIVE_LINK_REGEX = /(?:\]\()(?:\s*)(?:\.\.?)\//g;
|
||||
|
||||
const ALLOWED_LINKS = ["/docs/llamaflow", "/docs/chat-ui"];
|
||||
|
||||
interface LinkValidationResult {
|
||||
file: string;
|
||||
invalidLinks: Array<{ link: string; line: number }>;
|
||||
@@ -29,14 +28,14 @@ interface RelativeLinkResult {
|
||||
* Get all valid documentation routes from the content directory
|
||||
*/
|
||||
async function getValidRoutes(): Promise<Set<string>> {
|
||||
const mdxFiles = await glob("**/*.{md,mdx}", { cwd: CONTENT_DIR });
|
||||
const mdxFiles = await glob("**/*.mdx", { cwd: CONTENT_DIR });
|
||||
|
||||
const routes = new Set<string>();
|
||||
|
||||
// Add each MDX file as a valid route
|
||||
for (const file of mdxFiles) {
|
||||
// Remove .mdx extension and normalize to route format
|
||||
let route = file.replace(/\.mdx?$/, "");
|
||||
let route = file.replace(/\.mdx$/, "");
|
||||
|
||||
// Handle index files
|
||||
if (route.endsWith("/index")) {
|
||||
@@ -125,6 +124,9 @@ function findRelativeLinksInFile(
|
||||
return relativeLinks;
|
||||
}
|
||||
|
||||
/**
|
||||
* Validate internal links in all MDX files
|
||||
*/
|
||||
/**
|
||||
* Find relative links in all MDX files
|
||||
*/
|
||||
@@ -158,11 +160,6 @@ async function validateLinks(): Promise<LinkValidationResult[]> {
|
||||
const links = extractLinksFromFile(filePath);
|
||||
|
||||
const invalidLinks = links.filter(({ link }) => {
|
||||
// Check if the link is in the allowed list
|
||||
if (ALLOWED_LINKS.includes(`/docs/${link}`)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Check if the link exists in valid routes
|
||||
// First normalize the link (remove any query string or hash)
|
||||
const baseLink = link.split("?")[0].split("#")[0];
|
||||
|
||||
@@ -1,19 +1,13 @@
|
||||
import {
|
||||
rehypeCodeDefaultOptions,
|
||||
remarkStructure,
|
||||
} from "fumadocs-core/mdx-plugins";
|
||||
import { rehypeCodeDefaultOptions } from "fumadocs-core/mdx-plugins";
|
||||
import { fileGenerator, remarkDocGen, remarkInstall } from "fumadocs-docgen";
|
||||
import { defineConfig, defineDocs } from "fumadocs-mdx/config";
|
||||
import { transformerTwoslash } from "fumadocs-twoslash";
|
||||
import { createFileSystemTypesCache } from "fumadocs-twoslash/cache-fs";
|
||||
import rehypeKatex from "rehype-katex";
|
||||
import remarkMath from "remark-math";
|
||||
|
||||
export const docs = defineDocs({
|
||||
dir: [
|
||||
"./src/content/docs",
|
||||
"./node_modules/@llama-flow/docs",
|
||||
"./node_modules/@llamaindex/chat-ui-docs",
|
||||
],
|
||||
dir: ["./src/content/docs", "./node_modules/@llama-flow/docs"],
|
||||
docs: {
|
||||
async: true,
|
||||
},
|
||||
@@ -30,7 +24,11 @@ export default defineConfig({
|
||||
},
|
||||
transformers: [
|
||||
...(rehypeCodeDefaultOptions.transformers ?? []),
|
||||
transformerTwoslash(),
|
||||
transformerTwoslash({
|
||||
typesCache: createFileSystemTypesCache({
|
||||
dir: ".next/cache/twoslash",
|
||||
}),
|
||||
}),
|
||||
{
|
||||
name: "transformers:remove-notation-escape",
|
||||
code(hast) {
|
||||
@@ -51,7 +49,6 @@ export default defineConfig({
|
||||
],
|
||||
},
|
||||
remarkPlugins: [
|
||||
remarkStructure,
|
||||
remarkMath,
|
||||
[remarkInstall, { persist: { id: "package-manager" } }],
|
||||
[remarkDocGen, { generators: [fileGenerator()] }],
|
||||
|
||||
@@ -26,7 +26,7 @@ const llm = openai();
|
||||
const response = await llm.chat({
|
||||
messages: [{ content: "Tell me a joke.", role: "user" }],
|
||||
});`,
|
||||
`import { agent } from "@llamaindex/workflow";
|
||||
`import { agent } from "llamaindex";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
|
||||
const analyseAgent = agent({
|
||||
@@ -36,7 +36,7 @@ const analyseAgent = agent({
|
||||
});
|
||||
const response = await analyseAgent.run(\`Analyse the given data:
|
||||
\${data}\`);`,
|
||||
`import { agent, multiAgent } from "@llamaindex/workflow";
|
||||
`import { agent, multiAgent } from "llamaindex";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
|
||||
const analyseAgent = agent({
|
||||
@@ -113,9 +113,8 @@ export default function HomePage() {
|
||||
description="Truly powerful retrieval-augmented generation applications use agentic techniques, and LlamaIndex.TS makes it easy to build them."
|
||||
>
|
||||
<CodeBlock
|
||||
code={`import { SimpleDirectoryReader, VectorStoreIndex } from "llamaindex";
|
||||
code={`import { agent, SimpleDirectoryReader, VectorStoreIndex } from "llamaindex";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
|
||||
// load documents from current directoy into an index
|
||||
const reader = new SimpleDirectoryReader();
|
||||
|
||||
@@ -4,7 +4,7 @@ import { createFromSource } from "fumadocs-core/search/server";
|
||||
|
||||
// TODO: migrate to another search service, I don't think Vercel can handle that many of documents.
|
||||
export const { GET } = createFromSource(source, (page) => ({
|
||||
id: page.file.path,
|
||||
id: page.url,
|
||||
title: page.data.title,
|
||||
description: page.data.description,
|
||||
url: page.url,
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
import { ChatDemoRSC } from "@/components/demo/chat/rsc/demo";
|
||||
import * as demos from "@/components/demo/lazy";
|
||||
import { createMetadata, metadataImage } from "@/lib/metadata";
|
||||
import { openapi, source } from "@/lib/source";
|
||||
@@ -50,6 +51,7 @@ export default async function Page(props: {
|
||||
...Icons,
|
||||
...defaultMdxComponents,
|
||||
...demos,
|
||||
ChatDemoRSC,
|
||||
Accordion,
|
||||
Accordions,
|
||||
APIPage: (props) => <APIPage {...openapi.getAPIPageProps(props)} />,
|
||||
|
||||
@@ -1,7 +1,11 @@
|
||||
import { baseOptions } from "@/app/layout.config";
|
||||
import { AITrigger } from "@/components/ai-chat";
|
||||
import { buttonVariants } from "@/components/ui/button";
|
||||
import { source } from "@/lib/source";
|
||||
import { cn } from "@/lib/utils";
|
||||
import "fumadocs-twoslash/twoslash.css";
|
||||
import { DocsLayout } from "fumadocs-ui/layouts/docs";
|
||||
import { MessageCircle } from "lucide-react";
|
||||
import type { ReactNode } from "react";
|
||||
|
||||
export default function Layout({ children }: { children: ReactNode }) {
|
||||
@@ -9,9 +13,23 @@ export default function Layout({ children }: { children: ReactNode }) {
|
||||
<DocsLayout
|
||||
tree={source.pageTree}
|
||||
{...baseOptions}
|
||||
links={[]}
|
||||
nav={{
|
||||
...baseOptions.nav,
|
||||
children: (
|
||||
<AITrigger
|
||||
className={cn(
|
||||
buttonVariants({
|
||||
variant: "secondary",
|
||||
size: "xs",
|
||||
className:
|
||||
"text-fd-muted-foreground ms-2 gap-1.5 rounded-full px-2 md:flex-1",
|
||||
}),
|
||||
)}
|
||||
>
|
||||
<MessageCircle className="size-3" />
|
||||
Ask LlamaCloud
|
||||
</AITrigger>
|
||||
),
|
||||
}}
|
||||
>
|
||||
{children}
|
||||
|
||||
@@ -27,19 +27,9 @@ export const baseOptions: BaseLayoutProps = {
|
||||
githubUrl: "https://github.com/run-llama/LlamaIndexTS",
|
||||
links: [
|
||||
{
|
||||
text: "TypeScript",
|
||||
text: "Docs",
|
||||
url: DOCUMENT_URL,
|
||||
active: "nested-url",
|
||||
},
|
||||
{
|
||||
text: "Python",
|
||||
url: "https://docs.llamaindex.ai",
|
||||
active: "url",
|
||||
},
|
||||
{
|
||||
text: "LlamaCloud",
|
||||
url: "https://docs.cloud.llamaindex.ai/",
|
||||
active: "url",
|
||||
},
|
||||
],
|
||||
};
|
||||
|
||||
@@ -13,7 +13,11 @@ import remarkStringify from "remark-stringify";
|
||||
export const revalidate = false;
|
||||
|
||||
export async function GET() {
|
||||
const files = await fg(["./src/content/docs/**/*.mdx"]);
|
||||
const files = await fg([
|
||||
"./src/content/docs/**/*.mdx",
|
||||
// remove generated openapi files
|
||||
"!./src/content/docs/cloud/api/**/*",
|
||||
]);
|
||||
|
||||
const scan = files.map(async (file) => {
|
||||
const fileContent = await fs.readFile(file);
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
"use client";
|
||||
import {
|
||||
ChatHandler,
|
||||
ChatInput,
|
||||
ChatMessages,
|
||||
ChatSection,
|
||||
} from "@llamaindex/chat-ui";
|
||||
import { useChat } from "ai/react";
|
||||
|
||||
export const ChatDemo = () => {
|
||||
const handler = useChat();
|
||||
return (
|
||||
<ChatSection handler={handler as ChatHandler}>
|
||||
<ChatMessages>
|
||||
<ChatMessages.List className="h-auto max-h-[400px]" />
|
||||
<ChatMessages.Actions />
|
||||
</ChatMessages>
|
||||
<ChatInput />
|
||||
</ChatSection>
|
||||
);
|
||||
};
|
||||
@@ -0,0 +1,57 @@
|
||||
import { Markdown } from "@llamaindex/chat-ui/widgets";
|
||||
import { MockLLM } from "@llamaindex/core/utils";
|
||||
import { generateId, Message } from "ai";
|
||||
import { createAI, createStreamableUI, getMutableAIState } from "ai/rsc";
|
||||
import { type ChatMessage, Settings, SimpleChatEngine } from "llamaindex";
|
||||
import { ReactNode } from "react";
|
||||
|
||||
type ServerState = Message[];
|
||||
type FrontendState = Array<Message & { display: ReactNode }>;
|
||||
type Actions = {
|
||||
chat: (message: Message) => Promise<Message & { display: ReactNode }>;
|
||||
};
|
||||
|
||||
Settings.llm = new MockLLM(); // config your LLM here
|
||||
|
||||
export const AI = createAI<ServerState, FrontendState, Actions>({
|
||||
initialAIState: [],
|
||||
initialUIState: [],
|
||||
actions: {
|
||||
chat: async (message: Message) => {
|
||||
"use server";
|
||||
|
||||
const aiState = getMutableAIState<typeof AI>();
|
||||
aiState.update((prev) => [...prev, message]);
|
||||
|
||||
const uiStream = createStreamableUI();
|
||||
const chatEngine = new SimpleChatEngine();
|
||||
const assistantMessage: Message = {
|
||||
id: generateId(),
|
||||
role: "assistant",
|
||||
content: "",
|
||||
};
|
||||
|
||||
// run the async function without blocking
|
||||
(async () => {
|
||||
const chatResponse = await chatEngine.chat({
|
||||
stream: true,
|
||||
message: message.content,
|
||||
chatHistory: aiState.get() as ChatMessage[],
|
||||
});
|
||||
|
||||
for await (const chunk of chatResponse) {
|
||||
assistantMessage.content += chunk.delta;
|
||||
uiStream.update(<Markdown content={assistantMessage.content} />);
|
||||
}
|
||||
|
||||
aiState.done([...aiState.get(), assistantMessage]);
|
||||
uiStream.done();
|
||||
})();
|
||||
|
||||
return {
|
||||
...assistantMessage,
|
||||
display: uiStream.value,
|
||||
};
|
||||
},
|
||||
},
|
||||
});
|
||||
@@ -0,0 +1,35 @@
|
||||
"use client";
|
||||
|
||||
import {
|
||||
ChatHandler,
|
||||
ChatInput,
|
||||
ChatMessage,
|
||||
ChatMessages,
|
||||
ChatSection as ChatSectionUI,
|
||||
Message,
|
||||
} from "@llamaindex/chat-ui";
|
||||
import { useChatRSC } from "./use-chat-rsc";
|
||||
|
||||
export const ChatSectionRSC = () => {
|
||||
const handler = useChatRSC();
|
||||
return (
|
||||
<ChatSectionUI handler={handler as ChatHandler}>
|
||||
<ChatMessages>
|
||||
<ChatMessages.List className="h-auto max-h-[400px]">
|
||||
{handler.messages.map((message, index) => (
|
||||
<ChatMessage
|
||||
key={index}
|
||||
message={message as Message}
|
||||
isLast={index === handler.messages.length - 1}
|
||||
>
|
||||
<ChatMessage.Avatar />
|
||||
<ChatMessage.Content>{message.display}</ChatMessage.Content>
|
||||
</ChatMessage>
|
||||
))}
|
||||
<ChatMessages.Loading />
|
||||
</ChatMessages.List>
|
||||
</ChatMessages>
|
||||
<ChatInput />
|
||||
</ChatSectionUI>
|
||||
);
|
||||
};
|
||||
@@ -0,0 +1,8 @@
|
||||
import { AI } from "./ai-action";
|
||||
import { ChatSectionRSC } from "./chat-section";
|
||||
|
||||
export const ChatDemoRSC = () => (
|
||||
<AI>
|
||||
<ChatSectionRSC />
|
||||
</AI>
|
||||
);
|
||||
@@ -0,0 +1,41 @@
|
||||
"use client";
|
||||
|
||||
import { useActions } from "ai/rsc";
|
||||
|
||||
import { generateId, Message } from "ai";
|
||||
import { useUIState } from "ai/rsc";
|
||||
import { useState } from "react";
|
||||
import { AI } from "./ai-action";
|
||||
|
||||
export function useChatRSC() {
|
||||
const [input, setInput] = useState<string>("");
|
||||
const [isLoading, setIsLoading] = useState<boolean>(false);
|
||||
const [messages, setMessages] = useUIState<typeof AI>();
|
||||
const { chat } = useActions<typeof AI>();
|
||||
|
||||
const append = async (message: Omit<Message, "id">) => {
|
||||
const newMsg: Message = { ...message, id: generateId() };
|
||||
|
||||
setIsLoading(true);
|
||||
try {
|
||||
setMessages((prev) => [...prev, { ...newMsg, display: message.content }]);
|
||||
const assistantMsg = await chat(newMsg);
|
||||
setMessages((prev) => [...prev, assistantMsg]);
|
||||
} catch (error) {
|
||||
console.error(error);
|
||||
}
|
||||
setIsLoading(false);
|
||||
setInput("");
|
||||
|
||||
return message.content;
|
||||
};
|
||||
|
||||
return {
|
||||
input,
|
||||
setInput,
|
||||
isLoading,
|
||||
messages,
|
||||
setMessages,
|
||||
append,
|
||||
};
|
||||
}
|
||||
@@ -1,8 +1,18 @@
|
||||
"use client";
|
||||
import dynamic from "next/dynamic";
|
||||
|
||||
// lazy load client components
|
||||
export const ChatDemo = dynamic(() =>
|
||||
import("@/components/demo/chat/api/demo").then((mod) => mod.ChatDemo),
|
||||
);
|
||||
|
||||
export const CodeNodeParserDemo = dynamic(() =>
|
||||
import("@/components/demo/code-node-parser").then(
|
||||
(mod) => mod.CodeNodeParserDemo,
|
||||
),
|
||||
);
|
||||
export const WorkflowStreamingDemo = dynamic(() =>
|
||||
import("@/components/demo/workflow-streaming-ui").then(
|
||||
(mod) => mod.WorkflowStreamingDemo,
|
||||
),
|
||||
);
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
"use client";
|
||||
import FlowInput from "@/components/flow-input";
|
||||
import { Button } from "@/components/ui/button";
|
||||
import {
|
||||
StartEvent,
|
||||
StopEvent,
|
||||
Workflow,
|
||||
WorkflowEvent,
|
||||
} from "@llamaindex/workflow";
|
||||
import { ReactNode, startTransition, useState } from "react";
|
||||
import { StickToBottom, useStickToBottomContext } from "use-stick-to-bottom";
|
||||
|
||||
class ComputeEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class ComputeResultEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
type ContextData = {
|
||||
sum: number;
|
||||
};
|
||||
|
||||
const workflow = new Workflow<ContextData, number, number>();
|
||||
|
||||
const max = 1000;
|
||||
const min = 100;
|
||||
|
||||
workflow.addStep(
|
||||
{
|
||||
inputs: [StartEvent<number>],
|
||||
outputs: [StopEvent<number>],
|
||||
},
|
||||
async (context, event) => {
|
||||
const total = event.data;
|
||||
for (let i = 0; i < total; i++) {
|
||||
context.sendEvent(new ComputeEvent(i));
|
||||
}
|
||||
console.log("waiting");
|
||||
const computeResults = await Promise.all(
|
||||
Array.from({ length: total }).map(() =>
|
||||
context.requireEvent(ComputeResultEvent),
|
||||
),
|
||||
);
|
||||
context.data.sum = computeResults.reduce(
|
||||
(acc, result) => acc + result.data,
|
||||
0,
|
||||
);
|
||||
console.log("stop");
|
||||
return new StopEvent(context.data.sum);
|
||||
},
|
||||
);
|
||||
|
||||
workflow.addStep(
|
||||
{
|
||||
inputs: [ComputeEvent],
|
||||
outputs: [ComputeResultEvent],
|
||||
},
|
||||
async (context, event) => {
|
||||
await new Promise((resolve) =>
|
||||
setTimeout(resolve, Math.floor(Math.random() * (max - min + 1) + min)),
|
||||
);
|
||||
return new ComputeResultEvent(event.data);
|
||||
},
|
||||
);
|
||||
|
||||
function ScrollToBottom() {
|
||||
const { isAtBottom, scrollToBottom } = useStickToBottomContext();
|
||||
|
||||
return (
|
||||
!isAtBottom && (
|
||||
<button
|
||||
className="i-ph-arrow-circle-down-fill absolute bottom-0 left-[50%] translate-x-[-50%] rounded-lg text-4xl"
|
||||
onClick={() => scrollToBottom()}
|
||||
/>
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
export function WorkflowStreamingDemo() {
|
||||
const [ui, setUI] = useState<ReactNode[]>([
|
||||
<div key={0} className="bg-gray-100 dark:bg-gray-800">
|
||||
Waiting for workflow to start
|
||||
</div>,
|
||||
]);
|
||||
const [total, setTotal] = useState<number>(10);
|
||||
|
||||
return (
|
||||
<div className="flex w-full flex-col items-start gap-2">
|
||||
<div className="flex flex-row items-center justify-center">
|
||||
<div className="mr-2 text-lg">Compute total</div>{" "}
|
||||
<FlowInput value={total} onChange={(value) => setTotal(value)} />
|
||||
</div>
|
||||
<Button
|
||||
onClick={async () => {
|
||||
startTransition(() => {
|
||||
setUI([]);
|
||||
});
|
||||
const context = workflow.run(total, {
|
||||
sum: 0,
|
||||
});
|
||||
let i = 0;
|
||||
for await (const event of context) {
|
||||
console.log(event);
|
||||
if (event instanceof ComputeEvent) {
|
||||
setUI((ui) => [
|
||||
...ui,
|
||||
<div key={i++} className="bg-yellow-100 dark:bg-yellow-800">
|
||||
Computing task id: {event.data}
|
||||
</div>,
|
||||
]);
|
||||
} else if (event instanceof ComputeResultEvent) {
|
||||
setUI((ui) => [
|
||||
...ui,
|
||||
<div key={i++} className="bg-green-100 dark:bg-green-800">
|
||||
Computed task id: {event.data}
|
||||
</div>,
|
||||
]);
|
||||
} else if (event instanceof StartEvent) {
|
||||
setUI((ui) => [
|
||||
...ui,
|
||||
<div key={i++} className="bg-blue-100 dark:bg-blue-800">
|
||||
Started workflow with total {event.data}
|
||||
</div>,
|
||||
]);
|
||||
} else if (event instanceof StopEvent) {
|
||||
setUI((ui) => [
|
||||
...ui,
|
||||
<div key={i++} className="bg-red-100 dark:bg-red-800">
|
||||
Workflow stopped
|
||||
</div>,
|
||||
]);
|
||||
}
|
||||
}
|
||||
}}
|
||||
>
|
||||
Start Workflow
|
||||
</Button>
|
||||
<StickToBottom className="flex max-h-96 w-full flex-col gap-2 overflow-y-auto rounded-lg border border-gray-200 p-2">
|
||||
<StickToBottom.Content className="flex flex-col gap-2">
|
||||
{ui}
|
||||
</StickToBottom.Content>
|
||||
<ScrollToBottom />
|
||||
</StickToBottom>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: LlamaCloud
|
||||
description: LlamaCloud is a new generation of managed parsing, ingestion, and retrieval services, designed to bring production-grade context-augmentation to your LLM and RAG applications.
|
||||
---
|
||||
|
||||
This is TypeScript binding for LlamaCloud API. It provides a simple way to interact with LlamaCloud API.
|
||||
|
||||
If you are looking for the official documentation, please visit the [Official Document](https://docs.cloud.llamaindex.ai/)
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"title": "LlamaCloud",
|
||||
"description": "The Cloud framework for LLM",
|
||||
"root": true,
|
||||
"pages": ["---Guide---", "index", "..."]
|
||||
}
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: High-Level Concepts
|
||||
---
|
||||
|
||||
This is a quick guide to the high-level concepts you'll encounter frequently when building LLM applications.
|
||||
|
||||
## Large Language Models (LLMs)
|
||||
|
||||
LLMs are the fundamental innovation that launched LlamaIndex. They are an artificial intelligence (AI) computer system that can understand, generate, and manipulate natural language, including answering questions based on their training data or data provided to them at query time.
|
||||
|
||||
## Agentic Applications
|
||||
|
||||
When an LLM is used within an application, it is often used to make decisions, take actions, and/or interact with the world. This is the core definition of an **agentic application**.
|
||||
|
||||
While the definition of an agentic application is broad, there are several key characteristics that define an agentic application:
|
||||
|
||||
- **LLM Augmentation**: The LLM is augmented with tools (i.e. arbitrary callable functions in code), memory, and/or dynamic prompts.
|
||||
- **Prompt Chaining**: Several LLM calls are used that build on each other, with the output of one LLM call being used as the input to the next.
|
||||
- **Routing**: The LLM is used to route the application to the next appropriate step or state in the application.
|
||||
- **Parallelism**: The application can perform multiple steps or actions in parallel.
|
||||
- **Orchestration**: A hierarchical structure of LLMs is used to orchestrate lower-level actions and LLMs.
|
||||
- **Reflection**: The LLM is used to reflect and validate outputs of previous steps or LLM calls, which can be used to guide the application to the next appropriate step or state.
|
||||
|
||||
In LlamaIndex, you can build agentic applications by using the workflows to orchestrate a sequence of steps and LLMs. You can [learn more about workflows](/docs/llamaindex/tutorials/workflows).
|
||||
|
||||
## Agents
|
||||
|
||||
We define an agent as a specific instance of an "agentic application". An agent is a piece of software that semi-autonomously performs tasks by combining LLMs with other tools and memory, orchestrated in a reasoning loop that decides which tool to use next (if any).
|
||||
|
||||
What this means in practice, is something like:
|
||||
- An agent receives a user message
|
||||
- The agent uses an LLM to determine the next appropriate action to take using the previous chat history, tools, and the latest user message
|
||||
- The agent may invoke one or more tools to assist in the users request
|
||||
- If tools are used, the agent will then interpret the tool outputs and use them to inform the next action
|
||||
- Once the agent stops taking actions, it returns the final output to the user
|
||||
|
||||
You can [learn more about agents](/docs/llamaindex/tutorials/basic_agent).
|
||||
|
||||
## Retrieval Augmented Generation (RAG)
|
||||
|
||||
Retrieval-Augmented Generation (RAG) is a core technique for building data-backed LLM applications with LlamaIndex. It allows LLMs to answer questions about your private data by providing it to the LLM at query time, rather than training the LLM on your data. To avoid sending **all** of your data to the LLM every time, RAG indexes your data and selectively sends only the relevant parts along with your query. You can [learn more about RAG](/docs/llamaindex/tutorials/rag).
|
||||
|
||||
## Use cases
|
||||
|
||||
There are endless use cases for data-backed LLM applications but they can be roughly grouped into four categories:
|
||||
|
||||
[**Agents**](/docs/llamaindex/tutorials/basic_agent):
|
||||
An agent is an automated decision-maker powered by an LLM that interacts with the world via a set of [tools](/docs/llamaindex/modules/agents/tool). Agents can take an arbitrary number of steps to complete a given task, dynamically deciding on the best course of action rather than following pre-determined steps. This gives it additional flexibility to tackle more complex tasks.
|
||||
|
||||
[**Workflows**](/docs/llamaindex/tutorials/workflows):
|
||||
A Workflow in LlamaIndex is a specific event-driven abstraction that allows you to orchestrate a sequence of steps and LLMs calls. Workflows can be used to implement any agentic application, and are a core component of LlamaIndex.
|
||||
|
||||
[**Structured Data Extraction**](/docs/llamaindex/tutorials/structured_data_extraction):
|
||||
Pydantic extractors allow you to specify a precise data structure to extract from your data and use LLMs to fill in the missing pieces in a type-safe way. This is useful for extracting structured data from unstructured sources like PDFs, websites, and more, and is key to automating workflows.
|
||||
|
||||
[**Query Engines**](/docs/llamaindex/modules/rag/query_engines):
|
||||
A query engine is an end-to-end flow that allows you to ask questions over your data. It takes in a natural language query, and returns a response, along with reference context retrieved and passed to the LLM.
|
||||
|
||||
[**Chat Engines**](/docs/llamaindex/modules/rag/chat_engine):
|
||||
A chat engine is an end-to-end flow for having a conversation with your data (multiple back-and-forth instead of a single question-and-answer).
|
||||
@@ -9,10 +9,10 @@ To install llamaindex, run the following command:
|
||||
npm i llamaindex
|
||||
```
|
||||
|
||||
In most cases, you'll also need an LLM package and the Workflow package to use LlamaIndex. For example, to use the OpenAI LLM with agents, you would install the following:
|
||||
In most cases, you'll also need an LLM package to use LlamaIndex. For example, to use the OpenAI LLM, you would install the following:
|
||||
|
||||
```package-install
|
||||
npm i @llamaindex/openai @llamaindex/workflow
|
||||
npm i @llamaindex/openai
|
||||
```
|
||||
|
||||
Go to [LLM APIs](/docs/llamaindex/modules/models/llms) to find out how to use other LLMs.
|
||||
|
||||
@@ -40,7 +40,19 @@ Make sure to set [moduleResolution](https://www.typescriptlang.org/docs/handbook
|
||||
}
|
||||
```
|
||||
|
||||
We recommend using `bundler` or `nodenext`, but due to popularity of `node`, we still added support for it.
|
||||
We recommend using `bundler` or `nodenext`, but due to popularity of `node`, we still added support for it, but with import path limitations.
|
||||
|
||||
So you may encounter type errors when importing sub paths from the `llamaindex` package like:
|
||||
|
||||
```ts
|
||||
import { Settings } from "llamaindex";
|
||||
```
|
||||
|
||||
The simplest way to fix this without changing `moduleResolution` is to import directly from `llamaindex`:
|
||||
|
||||
```ts
|
||||
import { Settings } from "llamaindex";
|
||||
```
|
||||
|
||||
## Enable AsyncIterable for `Web Stream` API
|
||||
|
||||
@@ -56,8 +68,7 @@ Some modules uses `Web Stream` API like `ReadableStream` and `WritableStream`, y
|
||||
```
|
||||
|
||||
```typescript
|
||||
import { tool } from 'llamaindex'
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent, tool } from 'llamaindex'
|
||||
import { openai } from "@llamaindex/openai";
|
||||
|
||||
Settings.llm = openai({
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
{
|
||||
"title": "Getting Started",
|
||||
"pages": ["concepts", "installation", "create_llama", "examples"]
|
||||
"pages": ["installation", "create_llama", "examples"]
|
||||
}
|
||||
|
||||
@@ -12,8 +12,7 @@ Agent Workflows are a powerful system that enables you to create and orchestrate
|
||||
The simplest use case is creating a single agent with specific tools. Here's an example of creating an assistant that tells jokes:
|
||||
|
||||
```typescript
|
||||
import { tool } from "llamaindex";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent, tool } from "llamaindex";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
|
||||
// Define a joke-telling tool
|
||||
@@ -33,7 +32,7 @@ const jokeAgent = agent({
|
||||
|
||||
// Run the workflow
|
||||
const result = await jokeAgent.run("Tell me something funny");
|
||||
console.log(result.data.result); // Baby Llama is called cria
|
||||
console.log(result); // Baby Llama is called cria
|
||||
```
|
||||
|
||||
### Event Streaming
|
||||
@@ -41,17 +40,17 @@ console.log(result.data.result); // Baby Llama is called cria
|
||||
Agent Workflows provide a unified interface for event streaming, making it easy to track and respond to different events during execution:
|
||||
|
||||
```typescript
|
||||
import { agentToolCallEvent, agentStreamEvent } from "@llamaindex/workflow";
|
||||
import { AgentToolCall, AgentStream } from "llamaindex";
|
||||
|
||||
// Get the workflow execution context
|
||||
const events = jokeAgent.runStream("Tell me something funny");
|
||||
const context = workflow.run("Tell me something funny");
|
||||
|
||||
// Stream and handle events
|
||||
for await (const event of events) {
|
||||
if (agentToolCallEvent.include(event)) {
|
||||
for await (const event of context) {
|
||||
if (event instanceof AgentToolCall) {
|
||||
console.log(`Tool being called: ${event.data.toolName}`);
|
||||
}
|
||||
if (agentStreamEvent.include(event)) {
|
||||
if (event instanceof AgentStream) {
|
||||
process.stdout.write(event.data.delta);
|
||||
}
|
||||
}
|
||||
@@ -69,8 +68,7 @@ An Agent Workflow can orchestrate multiple agents, enabling complex interactions
|
||||
Here's an example of a multi-agent system that combines joke-telling and weather information:
|
||||
|
||||
```typescript
|
||||
import { tool } from "llamaindex";
|
||||
import { multiAgent, agent } from "@llamaindex/workflow";
|
||||
import { multiAgent, agent, tool } from "llamaindex";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
import { z } from "zod";
|
||||
|
||||
@@ -112,7 +110,6 @@ const agents = multiAgent({
|
||||
const result = await agents.run(
|
||||
"Give me a morning greeting with a joke and the weather in San Francisco"
|
||||
);
|
||||
console.log(result.data.result);
|
||||
```
|
||||
|
||||
The workflow will coordinate between agents, allowing them to handle different aspects of the request and hand off tasks when appropriate.
|
||||
|
||||
@@ -17,8 +17,7 @@ The `parameters` field in the tool configuration is defined using `zod`, a TypeS
|
||||
|
||||
Example:
|
||||
```ts
|
||||
import { tool } from "llamaindex";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent, tool } from "llamaindex";
|
||||
import { z } from "zod";
|
||||
|
||||
// first arg is LLM input, second is bound arg
|
||||
@@ -47,7 +46,7 @@ In this example, `z.object` is used to define a schema for the `parameters` wher
|
||||
You can import built-in tools from the `@llamaindex/tools` package.
|
||||
|
||||
```ts
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent } from "llamaindex";
|
||||
import { wiki } from "@llamaindex/tools";
|
||||
|
||||
const researchAgent = agent({
|
||||
@@ -58,41 +57,6 @@ const researchAgent = agent({
|
||||
});
|
||||
```
|
||||
|
||||
## MCP tools
|
||||
|
||||
If you have a MCP server running, you can fetch tools from the server and use them in your agents.
|
||||
|
||||
```ts
|
||||
// 1. Import MCP tools adapter
|
||||
import { mcp } from "@llamaindex/tools";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
|
||||
// 2. Initialize a MCP client
|
||||
// by npx
|
||||
const server = mcp({
|
||||
command: "npx",
|
||||
args: ["-y", "@modelcontextprotocol/server-filesystem", "."],
|
||||
verbose: true,
|
||||
});
|
||||
// or by SSE
|
||||
const server = mcp({
|
||||
url: "http://localhost:8000/mcp",
|
||||
verbose: true,
|
||||
});
|
||||
|
||||
// 3. Get tools from MCP server
|
||||
const tools = await server.tools();
|
||||
|
||||
// Now you can create an agent with the tools
|
||||
const agent = agent({
|
||||
name: "My Agent",
|
||||
systemPrompt: "You are a helpful assistant that can use the provided tools to answer questions.",
|
||||
llm: openai({ model: "gpt-4o" }),
|
||||
tools: tools,
|
||||
});
|
||||
```
|
||||
|
||||
|
||||
## Function tool
|
||||
|
||||
You can still use the `FunctionTool` class to define a tool.
|
||||
@@ -115,8 +79,7 @@ Note: calling the `bind` method will return a new `FunctionTool` instance, witho
|
||||
|
||||
Example to pass a `userToken` as additional argument:
|
||||
```ts
|
||||
import { tool } from "llamaindex";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent, tool } from "llamaindex";
|
||||
|
||||
// first arg is LLM input, second is bound arg
|
||||
const queryKnowledgeBase = async ({ question }, { userToken }) => {
|
||||
|
||||
@@ -2,17 +2,149 @@
|
||||
title: Workflows
|
||||
---
|
||||
|
||||
A `Workflow` in LlamaIndex is a lightweight, event-driven abstraction used to chain together several events. Workflows are made up of `handlers`, with each one responsible for processing specific event types and emitting new events.
|
||||
A `Workflow` in LlamaIndexTS is an event-driven abstraction used to chain together several events. Workflows are made up of `steps`, with each step responsible for handling certain event types and emitting new events.
|
||||
|
||||
Workflows are designed to be flexible and can be used to build agents, RAG flows, extraction flows, or anything else you want to implement.
|
||||
Workflows in LlamaIndexTS work by defining step functions that handle specific event types and emit new events.
|
||||
|
||||
When a step function is added to a workflow, you need to specify the input and optionally the output event types (used for validation). The specification of the input events ensures each step only runs when an accepted event is ready.
|
||||
|
||||
You can create a `Workflow` to do anything! Build an agent, a RAG flow, an extraction flow, or anything else you want.
|
||||
|
||||
To use workflows install this package:
|
||||
|
||||
```package-install
|
||||
npm i @llamaindex/workflow
|
||||
```
|
||||
|
||||
This package is a stable, production-ready version of our [llama-flow](/docs/llamaflow) project.
|
||||
## Getting Started
|
||||
|
||||
While you can still reference the llama-flow documentation for detailed information about the underlying concepts, we recommend using the `@llamaindex/workflow` package for all new projects to ensure stability and long-term availability.
|
||||
As an illustrative example, let's consider a naive workflow where a joke is generated and then critiqued.
|
||||
|
||||
<include cwd>../../examples/workflow/joke.ts</include>
|
||||
|
||||
There's a few moving pieces here, so let's go through this piece by piece.
|
||||
|
||||
### Defining Workflow Events
|
||||
|
||||
```typescript
|
||||
export class JokeEvent extends WorkflowEvent<{ joke: string }> {}
|
||||
```
|
||||
|
||||
Events are user-defined classes that extend `WorkflowEvent` and contain arbitrary data provided as template argument. In this case, our workflow relies on a single user-defined event, the `JokeEvent` with a `joke` attribute of type `string`.
|
||||
|
||||
### Setting up the Workflow Class
|
||||
|
||||
```typescript
|
||||
const llm = new OpenAI();
|
||||
...
|
||||
const jokeFlow = new Workflow<unknown, string, string>();
|
||||
```
|
||||
|
||||
Our workflow is implemented by initiating the `Workflow` class with three generic types: the context type (unknown), input type (string), and output type (string). The context type is `unknown`, as we're not using a shared context in this example.
|
||||
|
||||
For simplicity, we created an `OpenAI` llm instance that we're using for inference in our workflow.
|
||||
|
||||
### Workflow Entry Points
|
||||
|
||||
```typescript
|
||||
const generateJoke = async (_: unknown, ev: StartEvent<string>) => {
|
||||
const prompt = `Write your best joke about ${ev.data}.`;
|
||||
const response = await llm.complete({ prompt });
|
||||
return new JokeEvent({ joke: response.text });
|
||||
};
|
||||
```
|
||||
|
||||
Here, we come to the entry-point of our workflow. While events are user-defined, there are two special-case events, the `StartEvent` and the `StopEvent`. These events are predefined, but we can specify the payload type using generic types. We're using `StartEvent<string>` to indicate that we're going to send an input of type string.
|
||||
|
||||
To add this step to the workflow, we use the `addStep` method with an object specifying the input and output event types:
|
||||
|
||||
```typescript
|
||||
jokeFlow.addStep(
|
||||
{
|
||||
inputs: [StartEvent<string>],
|
||||
outputs: [JokeEvent],
|
||||
},
|
||||
generateJoke
|
||||
);
|
||||
```
|
||||
|
||||
### Workflow Exit Points
|
||||
|
||||
```typescript
|
||||
const critiqueJoke = async (_: unknown, ev: JokeEvent) => {
|
||||
const prompt = `Give a thorough critique of the following joke: ${ev.data.joke}`;
|
||||
const response = await llm.complete({ prompt });
|
||||
return new StopEvent(response.text);
|
||||
};
|
||||
```
|
||||
|
||||
Here, we have our second and last step in the workflow. We know it's the last step because the special `StopEvent` is returned. When the workflow encounters a returned `StopEvent`, it immediately stops the workflow and returns the result. Note that we're using the generic type `StopEvent<string>` to indicate that we're returning a string.
|
||||
|
||||
Add this step to the workflow:
|
||||
|
||||
```typescript
|
||||
jokeFlow.addStep(
|
||||
{
|
||||
inputs: [JokeEvent],
|
||||
outputs: [StopEvent<string>],
|
||||
},
|
||||
critiqueJoke
|
||||
);
|
||||
```
|
||||
|
||||
### Running the Workflow
|
||||
|
||||
```typescript
|
||||
const result = await jokeFlow.run("pirates");
|
||||
console.log(result.data.result);
|
||||
```
|
||||
|
||||
Lastly, we run the workflow. The `.run()` method is async, so we use await here to wait for the result.
|
||||
|
||||
## Working with Shared Context/State
|
||||
|
||||
Optionally, you can choose to use a shared context between steps by specifying a context type when creating the workflow. Here's an example where multiple steps access a shared state:
|
||||
|
||||
```typescript
|
||||
import { HandlerContext } from "llamaindex";
|
||||
|
||||
type MyContextData = {
|
||||
query: string;
|
||||
intermediateResults: any[];
|
||||
}
|
||||
|
||||
const query = async (context: HandlerContext<MyContextData>, ev: MyEvent) => {
|
||||
// get the query from the context
|
||||
const query = context.data.query;
|
||||
// do something with context and event
|
||||
const val = ...
|
||||
// store in context
|
||||
context.data.intermediateResults.push(val);
|
||||
|
||||
return new StopEvent({ result });
|
||||
};
|
||||
```
|
||||
|
||||
## Waiting for Multiple Events
|
||||
|
||||
The context does more than just hold data, it also provides utilities to buffer and wait for multiple events.
|
||||
|
||||
For example, you might have a step that waits for a query and retrieved nodes before synthesizing a response:
|
||||
|
||||
```typescript
|
||||
const synthesize = async (context: Context, ev1: QueryEvent, ev2: RetrieveEvent) => {
|
||||
const subPrompts = [`Answer this query using the context provided: ${ev1.data.query}`, `Context: ${ev2.data.context}`];
|
||||
const prompt = subPrompts.join("\n");
|
||||
const response = await llm.complete({ prompt });
|
||||
return new StopEvent({ result: response.text });
|
||||
};
|
||||
```
|
||||
|
||||
Passing multiple events, we can buffer and wait for ALL expected events to arrive. The receiving step function will only be called once all events have arrived.
|
||||
|
||||
## Manually Triggering Events
|
||||
|
||||
Normally, events are triggered by returning another event during a step. However, events can also be manually dispatched using the `ctx.sendEvent(event)` method within a workflow.
|
||||
|
||||
## Examples
|
||||
|
||||
You can find many useful examples of using workflows in the [examples folder](https://github.com/run-llama/LlamaIndexTS/blob/main/examples/workflow).
|
||||
|
||||
@@ -5,12 +5,6 @@ title: DiscordReader
|
||||
DiscordReader is a simple data loader that reads all messages in a given Discord channel and returns them as Document objects.
|
||||
It uses the [@discordjs/rest](https://github.com/discordjs/discord.js/tree/main/packages/rest) library to fetch the messages.
|
||||
|
||||
## Installation
|
||||
|
||||
```package-install
|
||||
npm install @llamaindex/discord
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
First step is to create a Discord Application and generating a bot token [here](https://discord.com/developers/applications).
|
||||
@@ -18,7 +12,7 @@ In your Discord Application, go to the `OAuth2` tab and generate an invite URL b
|
||||
This will invite the bot with the necessary permissions to read messages.
|
||||
Copy the URL in your browser and select the server you want your bot to join.
|
||||
|
||||
<include cwd>../../examples/readers/discord/reader.ts</include>
|
||||
<include cwd>../../examples/readers/src/discord.ts</include>
|
||||
|
||||
### Params
|
||||
|
||||
|
||||
@@ -21,18 +21,27 @@ To install readers call:
|
||||
|
||||
We offer readers for different file formats.
|
||||
|
||||
```ts twoslash
|
||||
import { CSVReader } from '@llamaindex/readers/csv';
|
||||
import { DocxReader } from '@llamaindex/readers/docx';
|
||||
import { HTMLReader } from '@llamaindex/readers/html';
|
||||
import { ImageReader } from '@llamaindex/readers/image';
|
||||
import { JSONReader } from '@llamaindex/readers/json';
|
||||
import { MarkdownReader } from '@llamaindex/readers/markdown';
|
||||
import { ObsidianReader } from '@llamaindex/readers/obsidian';
|
||||
import { PDFReader } from '@llamaindex/readers/pdf';
|
||||
import { TextFileReader } from '@llamaindex/readers/text';
|
||||
```ts twoslash
|
||||
import { CSVReader } from '@llamaindex/readers/csv'
|
||||
import { PDFReader } from '@llamaindex/readers/pdf'
|
||||
import { JSONReader } from '@llamaindex/readers/json'
|
||||
import { MarkdownReader } from '@llamaindex/readers/markdown'
|
||||
import { HTMLReader } from '@llamaindex/readers/html'
|
||||
// you can find more readers in the documentation
|
||||
```
|
||||
|
||||
Additionally the following loaders exist without separate documentation:
|
||||
|
||||
- `AssemblyAIReader` transcribes audio using [AssemblyAI](https://www.assemblyai.com/).
|
||||
- [AudioTranscriptReader](/docs/api/classes/AudioTranscriptReader): loads entire transcript as a single document.
|
||||
- [AudioTranscriptParagraphsReader](/docs/api/classes/AudioTranscriptParagraphsReader): creates a document per paragraph.
|
||||
- [AudioTranscriptSentencesReader](/docs/api/classes/AudioTranscriptSentencesReader): creates a document per sentence.
|
||||
- [AudioSubtitlesReader](/docs/api/classes/AudioTranscriptParagraphsReader): creates a document containing the subtitles of a transcript.
|
||||
- [NotionReader](/docs/api/classes/NotionReader) loads [Notion](https://www.notion.so/) pages.
|
||||
- [SimpleMongoReader](/docs/api/classes/SimpleMongoReader) loads data from a [MongoDB](https://www.mongodb.com/).
|
||||
|
||||
Check the [LlamaIndexTS Github](https://github.com/run-llama/LlamaIndexTS) for the most up to date overview of integrations.
|
||||
|
||||
## SimpleDirectoryReader
|
||||
|
||||
[Open in StackBlitz](https://stackblitz.com/github/run-llama/LlamaIndexTS/tree/main/examples/readers?file=src/simple-directory-reader.ts&title=Simple%20Directory%20Reader)
|
||||
|
||||
@@ -112,3 +112,6 @@ The returned `imageDocs` have the alt text assigned as text and the image path a
|
||||
|
||||
You can see the full example file [here](https://github.com/run-llama/LlamaIndexTS/blob/main/examples/readers/src/llamaparse-json.ts).
|
||||
|
||||
## API Reference
|
||||
|
||||
- [LlamaParseReader](/docs/api/classes/LlamaParseReader)
|
||||
|
||||
@@ -32,7 +32,7 @@ They can be divided into two groups.
|
||||
#### Advanced params:
|
||||
|
||||
- `resultType` can be set to `markdown`, `text` or `json`. Defaults to `text`. More information about `json` mode on the next pages.
|
||||
- `language` primarily helps with OCR recognition. Defaults to `en`.
|
||||
- `language` primarily helps with OCR recognition. Defaults to `en`. Click [here](/docs/api/type-aliases/Language) for a list of supported languages.
|
||||
- `parsingInstructions?` Optional. Can help with complicated document structures. See this [LlamaIndex Blog Post](https://www.llamaindex.ai/blog/launching-the-first-genai-native-document-parsing-platform) for an example.
|
||||
- `skipDiagonalText?` Optional. Set to true to ignore diagonal text. (Text that is not rotated 0, 90, 180 or 270 degrees)
|
||||
- `invalidateCache?` Optional. Set to true to ignore the LlamaCloud cache. All document are kept in cache for 48hours after the job was completed to avoid processing the same document twice. Can be useful for testing when trying to re-parse the same document with, e.g. different `parsingInstructions`.
|
||||
@@ -61,3 +61,4 @@ Below a full example of `LlamaParse` integrated in `SimpleDirectoryReader` with
|
||||
## API Reference
|
||||
|
||||
- [SimpleDirectoryReader](/docs/api/classes/SimpleDirectoryReader)
|
||||
- [LlamaParseReader](/docs/api/classes/LlamaParseReader)
|
||||
|
||||
@@ -98,4 +98,5 @@ You can assign any other values of the JSON response to the Document as needed.
|
||||
|
||||
## API Reference
|
||||
|
||||
- [LlamaParseReader](/docs/api/classes/LlamaParseReader)
|
||||
- [SimpleDirectoryReader](/docs/api/classes/SimpleDirectoryReader)
|
||||
|
||||
@@ -88,7 +88,7 @@ async function main() {
|
||||
|
||||
const response = await queryEngine.query({
|
||||
query: "What did the author do in college?",
|
||||
}); // Additional filters and params can be passed as options
|
||||
});
|
||||
|
||||
// Output response
|
||||
console.log(response.toString());
|
||||
|
||||
@@ -42,7 +42,6 @@ similarity float
|
||||
)
|
||||
language plpgsql
|
||||
as $$
|
||||
#variable_conflict use_column
|
||||
begin
|
||||
return query
|
||||
select
|
||||
|
||||
@@ -2,43 +2,89 @@
|
||||
title: Azure OpenAI
|
||||
---
|
||||
|
||||
To use Azure OpenAI, you only need to install the `@llamaindex/azure` package:
|
||||
To use Azure OpenAI, you only need to set a few environment variables together with the `OpenAI` class.
|
||||
|
||||
For example:
|
||||
|
||||
## Environment Variables
|
||||
|
||||
```
|
||||
export AZURE_OPENAI_KEY="<YOUR KEY HERE>"
|
||||
export AZURE_OPENAI_ENDPOINT="<YOUR ENDPOINT, see https://learn.microsoft.com/en-us/azure/ai-services/openai/quickstart?tabs=command-line%2Cpython&pivots=rest-api>"
|
||||
export AZURE_OPENAI_DEPLOYMENT="gpt-4" # or some other deployment name
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
```package-install
|
||||
npm i llamaindex @llamaindex/azure
|
||||
npm i llamaindex @llamaindex/openai
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
The class `AzureOpenAI` is used for setting the LLM and `AzureOpenAIEmbedding` is used for setting the embedding model, e.g.:
|
||||
|
||||
```ts
|
||||
import { Settings } from "llamaindex";
|
||||
import { AzureOpenAI, AzureOpenAIEmbedding } from "@llamaindex/azure";
|
||||
import { OpenAI } from "@llamaindex/openai";
|
||||
|
||||
Settings.llm = new AzureOpenAI({
|
||||
apiKey: '[key]',
|
||||
deployment: '[model]',
|
||||
apiVersion: '[version]',
|
||||
endpoint: `https://[deployment].openai.azure.com/`,
|
||||
});
|
||||
Settings.embedModel = new AzureOpenAIEmbedding({
|
||||
apiKey: '[key]',
|
||||
deployment: '[embedding-model]',
|
||||
apiVersion: '[version]',
|
||||
endpoint: `https://[deployment].openai.azure.com/`,
|
||||
Settings.llm = new OpenAI({ model: "gpt-4", temperature: 0 });
|
||||
```
|
||||
|
||||
## Load and index documents
|
||||
|
||||
For this example, we will use a single document. In a real-world scenario, you would have multiple documents to index.
|
||||
|
||||
```ts
|
||||
const document = new Document({ text: essay, id_: "essay" });
|
||||
|
||||
const index = await VectorStoreIndex.fromDocuments([document]);
|
||||
```
|
||||
|
||||
## Query
|
||||
|
||||
```ts
|
||||
const queryEngine = index.asQueryEngine();
|
||||
|
||||
const query = "What is the meaning of life?";
|
||||
|
||||
const results = await queryEngine.query({
|
||||
query,
|
||||
});
|
||||
```
|
||||
|
||||
Instead of explicitly setting the API key, deployment, version, and endpoint in the constructor, you can use the following environment variables: `AZURE_OPENAI_DEPLOYMENT` for the model deployment name, `AZURE_OPENAI_KEY` for your API key, `AZURE_OPENAI_ENDPOINT` for your Azure endpoint URL, and `AZURE_OPENAI_API_VERSION` for the API version.
|
||||
## Full Example
|
||||
|
||||
## Examples
|
||||
```ts
|
||||
import { Document, VectorStoreIndex, Settings } from "llamaindex";
|
||||
import { OpenAI } from "@llamaindex/openai";
|
||||
|
||||
See the [Azure examples](https://github.com/run-llama/LlamaIndexTS/tree/main/examples/storage/azure) for more examples of how to use Azure OpenAI.
|
||||
Settings.llm = new OpenAI({ model: "gpt-4", temperature: 0 });
|
||||
|
||||
async function main() {
|
||||
const document = new Document({ text: essay, id_: "essay" });
|
||||
|
||||
// Load and index documents
|
||||
const index = await VectorStoreIndex.fromDocuments([document]);
|
||||
|
||||
// get retriever
|
||||
const retriever = index.asRetriever();
|
||||
|
||||
// Create a query engine
|
||||
const queryEngine = index.asQueryEngine({
|
||||
retriever,
|
||||
});
|
||||
|
||||
const query = "What is the meaning of life?";
|
||||
|
||||
// Query
|
||||
const response = await queryEngine.query({
|
||||
query,
|
||||
});
|
||||
|
||||
// Log the response
|
||||
console.log(response.response);
|
||||
}
|
||||
```
|
||||
|
||||
## API Reference
|
||||
|
||||
- [AzureOpenAI](/docs/api/classes/AzureOpenAI)
|
||||
- [AzureOpenAIEmbedding](/docs/api/classes/AzureOpenAIEmbedding)
|
||||
- [OpenAI](/docs/api/classes/OpenAI)
|
||||
|
||||
@@ -120,11 +120,11 @@ async function main() {
|
||||
|
||||
```ts
|
||||
import { BEDROCK_MODELS, Bedrock } from "@llamaindex/community";
|
||||
import { tool } from "llamaindex";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { FunctionTool, LLMAgent } from "llamaindex";
|
||||
import { z } from "zod";
|
||||
|
||||
const sumNumbers = tool(
|
||||
const sumNumbers = FunctionTool.from(
|
||||
({ a, b }: { a: number; b: number }) => `${a + b}`,
|
||||
{
|
||||
name: "sumNumbers",
|
||||
description: "Use this function to sum two numbers",
|
||||
@@ -136,11 +136,11 @@ const sumNumbers = tool(
|
||||
description: "The second number",
|
||||
}),
|
||||
}),
|
||||
execute: ({ a, b }: { a: number; b: number }) => `${a + b}`,
|
||||
},
|
||||
);
|
||||
|
||||
const divideNumbers = tool(
|
||||
const divideNumbers = FunctionTool.from(
|
||||
({ a, b }: { a: number; b: number }) => `${a / b}`,
|
||||
{
|
||||
name: "divideNumbers",
|
||||
description: "Use this function to divide two numbers",
|
||||
@@ -152,7 +152,6 @@ const divideNumbers = tool(
|
||||
description: "The divisor b to divide by",
|
||||
}),
|
||||
}),
|
||||
execute: ({ a, b }: { a: number; b: number }) => `${a / b}`,
|
||||
},
|
||||
);
|
||||
|
||||
@@ -162,15 +161,15 @@ const bedrock = new Bedrock({
|
||||
});
|
||||
|
||||
async function main() {
|
||||
const myAgent = agent({
|
||||
const agent = new LLMAgent({
|
||||
llm: bedrock,
|
||||
tools: [sumNumbers, divideNumbers],
|
||||
});
|
||||
|
||||
const response = await myAgent.run(
|
||||
"How much is 5 + 5? then divide by 2",
|
||||
);
|
||||
const response = await agent.chat({
|
||||
message: "How much is 5 + 5? then divide by 2",
|
||||
});
|
||||
|
||||
console.log(response);
|
||||
console.log(response.message);
|
||||
}
|
||||
```
|
||||
|
||||
@@ -55,7 +55,7 @@ const results = await queryEngine.query({
|
||||
|
||||
## Full Example
|
||||
|
||||
<include cwd>../../examples/models/groq.ts</include>
|
||||
<include cwd>../../examples/groq.ts</include>
|
||||
|
||||
## API Reference
|
||||
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Using API Route
|
||||
description: Chat interface for your LlamaIndexTS application using API Route
|
||||
---
|
||||
|
||||
Using [chat-ui](https://github.com/run-llama/chat-ui), it's easy to add a chat interface to your LlamaIndexTS application.
|
||||
You just need to create an API route that provides an `api/chat` endpoint and a chat component to consume the API.
|
||||
|
||||
## API route
|
||||
|
||||
As an example, this is an API route for the Next.js App Router. Copy the following code into your `app/api/chat/route.ts` file to get started:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/app/api/chat/route.ts",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
## Chat UI
|
||||
|
||||
This is the simplest way to add a chat interface to your application. Copy the following code into your application to consume the API:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/components/demo/chat/api/demo.tsx",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
## Try it out ⬇️
|
||||
|
||||
Combining both, you're getting a fully functional chat interface:
|
||||
|
||||
<ChatDemo />
|
||||
|
||||
|
||||
## Next Steps
|
||||
|
||||
The steps above are the bare minimum to get a chat interface working. From here, you can go two ways:
|
||||
|
||||
1. Use [create-llama](https://github.com/run-llama/create-llama) to scaffold a new LlamaIndexTS project including complex API routes and chat interfaces or
|
||||
2. Learn more about [chat-ui](https://github.com/run-llama/chat-ui) and [LlamaIndexTS](https://github.com/run-llama/llamaindex-ts) to customize the chat interface and API routes to your needs.
|
||||
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: Using @llamaindex/chat-ui
|
||||
description: Chat UI components for your LlamaIndexTS application
|
||||
---
|
||||
|
||||
@llamaindex/chat-ui is a library that provides a set of components for building chat user interfaces. It is built on top of [Shadcn UI](https://ui.shadcn.com).
|
||||
|
||||
Check out our [chat-ui](/docs/chat-ui) documentation or try running examples on the [ui.llamaindex.ai](https://ui.llamaindex.ai) website.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Install @llamaindex/chat
|
||||
description: Chat interface for your LlamaIndexTS application
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
You can quickly add a chatbot to your project by using Shadcn CLI command:
|
||||
|
||||
```sh
|
||||
npx shadcn@latest add https://ui.llamaindex.ai/r/chat.json
|
||||
```
|
||||
|
||||
## Manual Installation
|
||||
|
||||
To install the package, run the following command in your project directory:
|
||||
|
||||
```sh
|
||||
npm i @llamaindex/chat-ui
|
||||
```
|
||||
|
||||
For more information, check out the [github.comrun-llama/chat-ui](https://github.com/run-llama/chat-ui)
|
||||
@@ -9,11 +9,145 @@ LlamaIndexServer is a Next.js-based application that allows you to quickly launc
|
||||
|
||||
## Features
|
||||
|
||||
- Add a sophisticated chatbot UI to your LlamaIndex workflow
|
||||
- Edit code and document artifacts in an OpenAI Canvas-style UI
|
||||
- Extendable UI components for events and headers
|
||||
- Serving a workflow as a chatbot
|
||||
- Built on Next.js for high performance and easy API development
|
||||
- Optional built-in chat UI with extendable UI components
|
||||
- Prebuilt development code
|
||||
|
||||
## Installation
|
||||
|
||||
```package-install
|
||||
npm i @llamaindex/server
|
||||
```
|
||||
|
||||
## Quick Start
|
||||
|
||||
Check the latest information on the NPM package page: https://www.npmjs.com/package/@llamaindex/server
|
||||
Create index.ts file and add the following code:
|
||||
|
||||
```ts
|
||||
import { LlamaIndexServer } from "@llamaindex/server";
|
||||
import { wiki } from "@llamaindex/tools"; // or any other tool
|
||||
|
||||
const createWorkflow = () => agent({ tools: [wiki()] })
|
||||
|
||||
new LlamaIndexServer({
|
||||
workflow: createWorkflow,
|
||||
uiConfig: {
|
||||
appTitle: "LlamaIndex App",
|
||||
starterQuestions: ["Who is the first president of the United States?"],
|
||||
},
|
||||
}).start();
|
||||
```
|
||||
|
||||
## Running the Server
|
||||
|
||||
In the same directory as `index.ts`, run the following command to start the server:
|
||||
|
||||
```bash
|
||||
tsx index.ts
|
||||
```
|
||||
The server will start at `http://localhost:3000`
|
||||
|
||||
You can also make a request to the server:
|
||||
|
||||
```bash
|
||||
curl -X POST "http://localhost:3000/api/chat" -H "Content-Type: application/json" -d '{"message": "Who is the first president of the United States?"}'
|
||||
```
|
||||
|
||||
## Configuration Options
|
||||
|
||||
The LlamaIndexServer accepts the following configuration
|
||||
|
||||
- `workflow`: A callable function that creates a workflow instance for each request
|
||||
- `uiConfig`: An object to configure the chat UI containing the following properties:
|
||||
- `appTitle`: The title of the application (default: `"LlamaIndex App"`)
|
||||
- `starterQuestions`: List of starter questions for the chat UI (default: `[]`)
|
||||
- `componentsDir`: The directory for custom UI components rendering events emitted by the workflow. The default is undefined, which does not render custom UI components.
|
||||
- `llamaCloudIndexSelector`: Whether to show the LlamaCloud index selector in the chat UI (requires `LLAMA_CLOUD_API_KEY` to be set in the environment variables) (default: `false`)
|
||||
|
||||
LlamaIndexServer accepts all the configuration options from Nextjs Custom Server such as `port`, `hostname`, `dev`, etc.
|
||||
See all Nextjs Custom Server options [here](https://nextjs.org/docs/app/building-your-application/configuring/custom-server).
|
||||
|
||||
## Default Endpoints and Features
|
||||
|
||||
### Chat Endpoint
|
||||
|
||||
The server includes a default chat endpoint at `/api/chat` for handling chat interactions.
|
||||
|
||||
### Chat UI
|
||||
|
||||
The server always provides a chat interface at the root path (`/`) with:
|
||||
|
||||
- Configurable starter questions
|
||||
- Real-time chat interface
|
||||
- API endpoint integration
|
||||
|
||||
### Static File Serving
|
||||
|
||||
- The server automatically mounts the `data` and `output` folders at `{server_url}{api_prefix}/files/data` (default: `/api/files/data`) and `{server_url}{api_prefix}/files/output` (default: `/api/files/output`) respectively.
|
||||
- Your workflows can use both folders to store and access files. As a convention, the `data` folder is used for documents that are ingested and the `output` folder is used for documents that are generated by the workflow.
|
||||
|
||||
|
||||
## Custom UI Components
|
||||
|
||||
The LlamaIndex server provides support for rendering workflow events using custom UI components, allowing you to extend and customize the chat interface.
|
||||
|
||||
### Overview
|
||||
|
||||
Custom UI components are a powerful feature that enables you to:
|
||||
|
||||
- Add custom interface elements to the chat UI using React JSX or TSX files
|
||||
- Extend the default chat interface functionality
|
||||
- Create specialized visualizations or interactions
|
||||
|
||||
### Configuration
|
||||
|
||||
Your workflow must emit events that fit this structure, allowing the LlamaIndex server to display the right UI components based on the event type.
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "<event_name>",
|
||||
"data": <data model>
|
||||
}
|
||||
```
|
||||
|
||||
### Server Setup
|
||||
|
||||
1. Initialize the LlamaIndex server with a component directory:
|
||||
|
||||
```ts
|
||||
new LlamaIndexServer({
|
||||
workflow: createWorkflow,
|
||||
uiConfig: {
|
||||
appTitle: "LlamaIndex App",
|
||||
componentsDir: "components",
|
||||
},
|
||||
}).start();
|
||||
```
|
||||
|
||||
2. Add the custom component code to the directory following the naming pattern:
|
||||
|
||||
- File Extension: `.jsx` and `.tsx` for React components
|
||||
- File Name: Should match the event type from your workflow (e.g., `deep_research_event.jsx` for handling `deep_research_event` type that you defined in your workflow). If there are TSX and JSX files with the same name, the TSX file will be used.
|
||||
- Component Name: Export a default React component named `Component` that receives props from the event data
|
||||
|
||||
Example component structure:
|
||||
|
||||
```jsx
|
||||
function Component({ events }) {
|
||||
// Your component logic here
|
||||
return (
|
||||
// Your UI code here
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. Always provide a workflow factory that creates fresh workflow instances
|
||||
2. Use environment variables for sensitive configuration
|
||||
3. Use starter questions to guide users in the chat UI
|
||||
|
||||
## Getting Started with a New Project
|
||||
|
||||
Want to start a new project with LlamaIndexServer? Check out our [create-llama](https://github.com/run-llama/create-llama) tool to quickly generate a new project with LlamaIndexServer.
|
||||
@@ -2,5 +2,5 @@
|
||||
"title": "Chat UI",
|
||||
"description": "Use chat-ui to add a chat interface to your LlamaIndexTS application.",
|
||||
"defaultOpen": false,
|
||||
"pages": ["index", "llamaindex-server"]
|
||||
"pages": ["install", "chat", "rsc", "llamaindex-server"]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Using Next.js RSC
|
||||
description: Chat interface for your LlamaIndexTS application using Next.js RSC
|
||||
---
|
||||
|
||||
Using [chat-ui](https://github.com/run-llama/chat-ui), it's easy to add a chat interface to your LlamaIndexTS application using [Next.js RSC](https://nextjs.org/docs/app/building-your-application/rendering/server-components) and [Vercel AI RSC](https://sdk.vercel.ai/docs/ai-sdk-rsc/overview).
|
||||
|
||||
With RSC, the chat messages are not returned as JSON from the server (like when using an [API route](/docs/llamaindex/modules/ui/chat)), instead the chat message components are rendered on the server side.
|
||||
This is for example useful for rendering a whole chat history on the server before sending it to the client. [Check here](https://sdk.vercel.ai/docs/getting-started/navigating-the-library#when-to-use-ai-sdk-rsc), for a discussion of when to use use RSC.
|
||||
|
||||
For implementing a chat interface with RSC, you need to create an AI action and then connect the chat interface to use it.
|
||||
|
||||
## Create an AI action
|
||||
|
||||
First, define an [AI context provider](https://sdk.vercel.ai/examples/rsc/state-management/ai-ui-states) with a chat server action:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/components/demo/chat/rsc/ai-action.tsx",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
The chat server action is using LlamaIndexTS to generate a response based on the chat history and the user input.
|
||||
|
||||
## Create the chat UI
|
||||
|
||||
The entrypoint of our application initializes the AI provider for the application and adds a `ChatSection` component:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/components/demo/chat/rsc/demo.tsx",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
The `ChatSection` component is created by using chat components from @llamaindex/chat-ui:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/components/demo/chat/rsc/chat-section.tsx",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
It is using a `useChatRSC` hook to conntect the chat interface to the `chat` AI action that we defined earlier:
|
||||
|
||||
```json doc-gen:file
|
||||
{
|
||||
"file": "./src/components/demo/chat/rsc/use-chat-rsc.tsx",
|
||||
"codeblock": true
|
||||
}
|
||||
```
|
||||
|
||||
## Try RSC Chat ⬇️
|
||||
|
||||
<ChatDemoRSC />
|
||||
|
||||
## Next Steps
|
||||
|
||||
The steps above are the bare minimum to get a chat interface working with RSC. From here, you can go two ways:
|
||||
|
||||
1. Use our [full-stack RSC example](https://github.com/run-llama/nextjs-rsc) based on [create-llama](https://github.com/run-llama/create-llama) to get started quickly with a fully working chat interface or
|
||||
2. Learn more about [AI RSC](https://sdk.vercel.ai/examples/rsc), [chat-ui](https://github.com/run-llama/chat-ui) and [LlamaIndexTS](https://github.com/run-llama/llamaindex-ts) to customize the chat interface and AI actions to your needs.
|
||||
|
||||
@@ -15,7 +15,7 @@ In LlamaIndex, an agent is a semi-autonomous piece of software powered by an LLM
|
||||
You'll need to have a recent version of [Node.js](https://nodejs.org/en) installed. Then you can install LlamaIndex.TS by running
|
||||
|
||||
```package-install
|
||||
npm i llamaindex @llamaindex/openai @llamaindex/readers @llamaindex/huggingface @llamaindex/workflow
|
||||
npm i llamaindex @llamaindex/openai @llamaindex/readers @llamaindex/huggingface
|
||||
```
|
||||
|
||||
## Choose your model
|
||||
|
||||
@@ -35,16 +35,11 @@ First we'll need to pull in our dependencies. These are:
|
||||
import "dotenv/config";
|
||||
import {
|
||||
agent,
|
||||
agentStreamEvent,
|
||||
openai,
|
||||
} from "@llamaindex/workflow";
|
||||
import {
|
||||
AgentStream,
|
||||
tool,
|
||||
openai,
|
||||
Settings,
|
||||
} from "llamaindex";
|
||||
import {
|
||||
openai,
|
||||
} from "@llamaindex/openai";
|
||||
import { z } from "zod";
|
||||
```
|
||||
|
||||
@@ -113,10 +108,11 @@ const myAgent = agent({ tools });
|
||||
|
||||
### Ask the agent a question
|
||||
|
||||
We can use the `run` method to ask our agent a question, and it will use the tools we've defined to find an answer.
|
||||
We can use the `chat` interface to ask our agent a question, and it will use the tools we've defined to find an answer.
|
||||
|
||||
```javascript
|
||||
const result = await myAgent.run("Sum 101 and 303");
|
||||
const context = myAgent.run("Sum 101 and 303");
|
||||
const result = await context;
|
||||
console.log(result.data);
|
||||
```
|
||||
You will see the following output:
|
||||
@@ -127,13 +123,12 @@ You will see the following output:
|
||||
{ result: 'The sum of 101 and 303 is 404.' }
|
||||
```
|
||||
|
||||
To stream the response, you need to call `runStream`, which returns a stream of events.
|
||||
The `agentStreamEvent` provides chunks of the response as they become available. This allows you to display the response incrementally rather than waiting for the full response:
|
||||
To stream the response, you can use the `AgentStream` event which provides chunks of the response as they become available. This allows you to display the response incrementally rather than waiting for the full response:
|
||||
|
||||
```javascript
|
||||
const events = myAgent.runStream("Add 101 and 303");
|
||||
for await (const event of events) {
|
||||
if (agentStreamEvent.include(event)) {
|
||||
const context = myAgent.run("Add 101 and 303");
|
||||
for await (const event of context) {
|
||||
if (event instanceof AgentStream) {
|
||||
process.stdout.write(event.data.delta);
|
||||
}
|
||||
}
|
||||
@@ -145,18 +140,18 @@ for await (const event of events) {
|
||||
The sum of 101 and 303 is 404.
|
||||
```
|
||||
|
||||
Note that we're filtering for `agentStreamEvent` as an agent might return other events - more about that in the following section.
|
||||
|
||||
### Logging workflow events
|
||||
|
||||
To log the workflow events, you can check the event type and log the event data.
|
||||
|
||||
```javascript
|
||||
const events = myAgent.runStream("Sum 202 and 404");
|
||||
for await (const event of events) {
|
||||
if (agentStreamEvent.include(event)) {
|
||||
const context = myAgent.run("Sum 202 and 404");
|
||||
for await (const event of context) {
|
||||
if (event instanceof AgentStream) {
|
||||
// Stream the response
|
||||
process.stdout.write(event.data.delta);
|
||||
for (const chunk of event.data.delta) {
|
||||
process.stdout.write(chunk);
|
||||
}
|
||||
} else {
|
||||
// Log other events
|
||||
console.log("\nWorkflow event:", JSON.stringify(event, null, 2));
|
||||
|
||||
@@ -30,16 +30,16 @@ Settings.llm = ollama({
|
||||
|
||||
### Run local agent
|
||||
|
||||
You can also create local agent by importing `agent` from `@llamaindex/workflow`.
|
||||
You can also create local agent by importing `agent` from `llamaindex`.
|
||||
|
||||
```javascript
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { agent } from "llamaindex";
|
||||
|
||||
const workflow = agent({
|
||||
tools: [getWeatherTool],
|
||||
});
|
||||
|
||||
const resutl = workflow.run(
|
||||
const workflowContext = workflow.run(
|
||||
"What's the weather like in San Francisco?",
|
||||
);
|
||||
```
|
||||
|
||||
@@ -25,8 +25,7 @@ We'll be bringing in `SimpleDirectoryReader`, `HuggingFaceEmbedding`, `VectorSto
|
||||
|
||||
```javascript
|
||||
import { QueryEngineTool, Settings, VectorStoreIndex } from "llamaindex";
|
||||
import { agent } from "@llamaindex/workflow";
|
||||
import { openai } from "@llamaindex/openai";
|
||||
import { OpenAI, OpenAIAgent } from "@llamaindex/openai";
|
||||
import { HuggingFaceEmbedding } from "@llamaindex/huggingface";
|
||||
import { SimpleDirectoryReader } from "@llamaindex/readers/directory";
|
||||
```
|
||||
@@ -59,9 +58,25 @@ We will convert our text into embeddings using the `VectorStoreIndex` class thro
|
||||
const index = await VectorStoreIndex.fromDocuments(documents);
|
||||
```
|
||||
|
||||
### Configure a retriever
|
||||
|
||||
Before LlamaIndex can send a query to the LLM, it needs to find the most relevant chunks to send. That's the purpose of a `Retriever`. We're going to get `VectorStoreIndex` to act as a retriever for us
|
||||
|
||||
```javascript
|
||||
const retriever = await index.asRetriever();
|
||||
```
|
||||
|
||||
### Configure how many documents to retrieve
|
||||
|
||||
By default LlamaIndex will retrieve just the 2 most relevant chunks of text. This document is complex though, so we'll ask for more context.
|
||||
|
||||
```javascript
|
||||
retriever.similarityTopK = 10;
|
||||
```
|
||||
|
||||
### Use index.queryTool
|
||||
|
||||
`index.queryTool` creates a `QueryEngineTool` that can be used be an agent to query data from the index:
|
||||
`index.queryTool` creates a `QueryEngineTool` that can be used be an agent to query data from the index.
|
||||
|
||||
```javascript
|
||||
const tools = [
|
||||
@@ -70,17 +85,9 @@ const tools = [
|
||||
name: "san_francisco_budget_tool",
|
||||
description: `This tool can answer detailed questions about the individual components of the budget of San Francisco in 2023-2024.`,
|
||||
},
|
||||
options: { similarityTopK: 10 },
|
||||
}),
|
||||
];
|
||||
```
|
||||
|
||||
The `metadata` that we're setting helps the agent to decide when to use the tool.
|
||||
Note that by default LlamaIndex will retrieve just the 2 most relevant chunks of text. This document is complex though, so we'll ask for more context by setting `similarityTopK` to 10.
|
||||
|
||||
Now, we can create an agent using the `QueryEngineTool`:
|
||||
|
||||
```javascript
|
||||
// Create an agent using the tools array
|
||||
const ragAgent = agent({ tools });
|
||||
|
||||
|
||||
@@ -12,7 +12,6 @@ const tools = [
|
||||
name: "san_francisco_budget_tool",
|
||||
description: `This tool can answer detailed questions about the individual components of the budget of San Francisco in 2023-2024.`,
|
||||
},
|
||||
options: { similarityTopK: 10 },
|
||||
}),
|
||||
tool({
|
||||
name: "sumNumbers",
|
||||
|
||||
@@ -8,10 +8,9 @@ We have a comprehensive, step-by-step [guide to building agents in LlamaIndex.TS
|
||||
|
||||
In a new folder:
|
||||
|
||||
```package-install
|
||||
```bash npm2yarn
|
||||
npm init
|
||||
npm i -D typescript @types/node
|
||||
npm i @llamaindex/openai @llamaindex/workflow llamaindex zod
|
||||
```
|
||||
|
||||
## Run agent
|
||||
@@ -21,14 +20,15 @@ Create the file `example.ts`. This code will:
|
||||
- Create two tools for use by the agent:
|
||||
- A `sumNumbers` tool that adds two numbers
|
||||
- A `divideNumbers` tool that divides numbers
|
||||
-
|
||||
- Give an example of the data structure we wish to generate
|
||||
- Prompt the LLM with instructions and the example, plus a sample transcript
|
||||
|
||||
<include cwd>../../examples/agents/agent/openai.ts</include>
|
||||
<include cwd>../../examples/agent/openai.ts</include>
|
||||
|
||||
To run the code:
|
||||
|
||||
```package-install
|
||||
```bash
|
||||
npx tsx example.ts
|
||||
```
|
||||
|
||||
@@ -36,18 +36,9 @@ You should expect output something like:
|
||||
|
||||
```
|
||||
{
|
||||
result: '5 + 5 is 10. Then, 10 divided by 2 is 5.',
|
||||
state: {
|
||||
memory: ChatMemoryBuffer {
|
||||
chatStore: SimpleChatStore {},
|
||||
chatStoreKey: 'chat_history',
|
||||
tokenLimit: 750000
|
||||
},
|
||||
scratchpad: [],
|
||||
currentAgentName: 'Agent',
|
||||
agents: [ 'Agent' ],
|
||||
nextAgentName: null
|
||||
}
|
||||
content: 'The sum of 5 + 5 is 10. When you divide 10 by 2, you get 5.',
|
||||
role: 'assistant',
|
||||
options: {}
|
||||
}
|
||||
Done
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
"basic_agent",
|
||||
"rag",
|
||||
"agents",
|
||||
"workflows",
|
||||
"workflow",
|
||||
"local_llm",
|
||||
"chatbot",
|
||||
"structured_data_extraction"
|
||||
|
||||
@@ -16,7 +16,7 @@ LlamaIndex uses a two stage method when using an LLM with your data:
|
||||
1. **indexing stage**: preparing a knowledge base, and
|
||||
2. **querying stage**: retrieving relevant context from the knowledge to assist the LLM in responding to a question
|
||||
|
||||

|
||||

|
||||
|
||||
This process is also known as Retrieval Augmented Generation (RAG).
|
||||
|
||||
@@ -28,7 +28,7 @@ Let's explore each stage in detail.
|
||||
|
||||
LlamaIndex.TS help you prepare the knowledge base with a suite of data connectors and indexes.
|
||||
|
||||

|
||||

|
||||
|
||||
[**Data Loaders**](/docs/llamaindex/modules/data/readers):
|
||||
A data connector (i.e. `Reader`) ingest data from different data sources and data formats into a simple `Document` representation (text and simple metadata).
|
||||
@@ -54,7 +54,7 @@ LlamaIndex provides composable modules that help you build and integrate RAG pip
|
||||
|
||||
These building blocks can be customized to reflect ranking preferences, as well as composed to reason over multiple knowledge bases in a structured way.
|
||||
|
||||

|
||||

|
||||
|
||||
#### Building Blocks
|
||||
|
||||
|
||||
@@ -8,10 +8,9 @@ One of the most common use-cases for LlamaIndex is Retrieval-Augmented Generatio
|
||||
|
||||
In a new folder, run:
|
||||
|
||||
```package-install
|
||||
```bash npm2yarn
|
||||
npm init
|
||||
npm i -D typescript @types/node
|
||||
npm i llamaindex
|
||||
```
|
||||
|
||||
Then, check out the [installation](/docs/llamaindex/getting_started/installation) steps to install LlamaIndex.TS and prepare an OpenAI key.
|
||||
@@ -27,7 +26,7 @@ Create the file `example.ts`. This code will
|
||||
- index it (which creates embeddings using OpenAI)
|
||||
- create a query engine to answer questions about the data
|
||||
|
||||
<include cwd>../../examples/index/vectorIndex.ts</include>
|
||||
<include cwd>../../examples/vectorIndex.ts</include>
|
||||
|
||||
Create a `tsconfig.json` file in the same folder:
|
||||
|
||||
@@ -35,7 +34,7 @@ Create a `tsconfig.json` file in the same folder:
|
||||
|
||||
Now you can run the code with
|
||||
|
||||
```package-install
|
||||
```bash
|
||||
npx tsx example.ts
|
||||
```
|
||||
|
||||
|
||||
@@ -10,10 +10,9 @@ You can use [other LLMs](/docs/llamaindex/modules/models/llms) via their APIs; i
|
||||
|
||||
In a new folder:
|
||||
|
||||
```package-install
|
||||
```bash npm2yarn
|
||||
npm init
|
||||
npm i -D typescript @types/node
|
||||
npm i @llamaindex/openai zod
|
||||
```
|
||||
|
||||
## Extract data
|
||||
@@ -24,11 +23,11 @@ Create the file `example.ts`. This code will:
|
||||
- Give an example of the data structure we wish to generate
|
||||
- Prompt the LLM with instructions and the example, plus a sample transcript
|
||||
|
||||
<include cwd>../../examples/misc/jsonExtract.ts</include>
|
||||
<include cwd>../../examples/jsonExtract.ts</include>
|
||||
|
||||
To run the code:
|
||||
|
||||
```package-install
|
||||
```bash
|
||||
npx tsx example.ts
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,530 @@
|
||||
---
|
||||
title: Advanced Event Handling
|
||||
description: Master complex event patterns and middleware with Workflows
|
||||
---
|
||||
|
||||
This guide explores advanced event handling techniques and patterns you can use with Workflows to build more sophisticated patterns.
|
||||
|
||||
## Event Composition
|
||||
|
||||
Workflows allow you to work with different event types and compose them in powerful ways:
|
||||
|
||||
### Multiple Event Types
|
||||
|
||||
You can define multiple event types for different kinds of data flowing through your workflow:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// Define different event types
|
||||
const textEvent = workflowEvent<string>();
|
||||
const numberEvent = workflowEvent<number>();
|
||||
const booleanEvent = workflowEvent<boolean>();
|
||||
const complexEvent = workflowEvent<{ id: string; value: number }>();
|
||||
|
||||
// Create a workflow that can process different event types
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Handle text events
|
||||
workflow.handle([textEvent], (event) => {
|
||||
console.log(`Processing text: ${event.data}`);
|
||||
return numberEvent.with(event.data.length);
|
||||
});
|
||||
|
||||
// Handle number events
|
||||
workflow.handle([numberEvent], (event) => {
|
||||
const isEven = event.data % 2 === 0;
|
||||
console.log(`Number ${event.data} is ${isEven ? 'even' : 'odd'}`);
|
||||
return booleanEvent.with(isEven);
|
||||
});
|
||||
|
||||
// Handle boolean events
|
||||
workflow.handle([booleanEvent], (event) => {
|
||||
return complexEvent.with({
|
||||
id: crypto.randomUUID(),
|
||||
value: event.data ? 100 : 0
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### Event Branching and Merging
|
||||
|
||||
You can create complex event flows with branching and merging patterns:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, until, collect } from "llamaindex";
|
||||
|
||||
// Define events for a data processing pipeline
|
||||
const inputEvent = workflowEvent<string>();
|
||||
const validateEvent = workflowEvent<string>();
|
||||
const processEvent = workflowEvent<string>();
|
||||
const errorEvent = workflowEvent<Error>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
const completeEvent = workflowEvent<string[]>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Branch based on input validation
|
||||
workflow.handle([inputEvent], (event) => {
|
||||
if (event.data && event.data.trim().length > 0) {
|
||||
return validateEvent.with(event.data.trim());
|
||||
} else {
|
||||
return errorEvent.with(new Error("Empty input"));
|
||||
}
|
||||
});
|
||||
|
||||
// Process valid inputs
|
||||
workflow.handle([validateEvent], (event) => {
|
||||
return processEvent.with(event.data.toUpperCase());
|
||||
});
|
||||
|
||||
// Handle processing
|
||||
workflow.handle([processEvent], (event) => {
|
||||
return resultEvent.with(`Processed: ${event.data}`);
|
||||
});
|
||||
|
||||
// Handle errors
|
||||
workflow.handle([errorEvent], (event) => {
|
||||
return resultEvent.with(`Error: ${event.data.message}`);
|
||||
});
|
||||
|
||||
// Merge results: collect multiple results into a single completion event
|
||||
workflow.handle([inputEvent], (start) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
|
||||
// Process all inputs
|
||||
const inputs = start.data.split(',').map(s => s.trim());
|
||||
inputs.forEach(input => sendEvent(inputEvent.with(input)));
|
||||
|
||||
// Collect all results
|
||||
const results = await collect(
|
||||
until(stream, result => resultEvent.include(result))
|
||||
.filter(ev => resultEvent.include(ev))
|
||||
.take(inputs.length)
|
||||
);
|
||||
|
||||
return completeEvent.with(results.map(r => r.data));
|
||||
});
|
||||
```
|
||||
|
||||
## Event Filtering and Transformation
|
||||
|
||||
You can filter and transform events to build sophisticated data processing pipelines:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const dataEvent = workflowEvent<number>();
|
||||
const evenEvent = workflowEvent<number>();
|
||||
const oddEvent = workflowEvent<number>();
|
||||
const transformedEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string[]>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Filter even numbers
|
||||
workflow.handle([dataEvent], (event) => {
|
||||
if (event.data % 2 === 0) {
|
||||
return evenEvent.with(event.data);
|
||||
} else {
|
||||
return oddEvent.with(event.data);
|
||||
}
|
||||
});
|
||||
|
||||
// Transform even numbers
|
||||
workflow.handle([evenEvent], (event) => {
|
||||
return transformedEvent.with(`Even: ${event.data}`);
|
||||
});
|
||||
|
||||
// Transform odd numbers
|
||||
workflow.handle([oddEvent], (event) => {
|
||||
return transformedEvent.with(`Odd: ${event.data}`);
|
||||
});
|
||||
|
||||
// Collect and organize results
|
||||
workflow.handle([dataEvent], (start) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
|
||||
// Generate a sequence of numbers
|
||||
for (let i = 1; i <= 10; i++) {
|
||||
sendEvent(dataEvent.with(i));
|
||||
}
|
||||
|
||||
// Collect transformed events
|
||||
const results = await collect(
|
||||
until(stream)
|
||||
.filter(ev => transformedEvent.include(ev))
|
||||
.take(10)
|
||||
);
|
||||
|
||||
return resultEvent.with(results.map(r => r.data));
|
||||
});
|
||||
```
|
||||
|
||||
## Working with `withTraceEvents` Middleware
|
||||
|
||||
The `withTraceEvents` middleware adds powerful tracing capabilities to your workflows:
|
||||
|
||||
```ts
|
||||
import {
|
||||
createWorkflow,
|
||||
workflowEvent,
|
||||
withTraceEvents,
|
||||
runOnce,
|
||||
createHandlerDecorator
|
||||
} from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const startEvent = workflowEvent<string>();
|
||||
const processEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow with tracing
|
||||
const workflow = withTraceEvents(createWorkflow());
|
||||
|
||||
// Create a custom handler decorator that logs execution time
|
||||
const measureTime = createHandlerDecorator({
|
||||
debugLabel: "measureTime",
|
||||
getInitialValue: () => performance.now(),
|
||||
onBeforeHandler: (handler, context, startTime) => {
|
||||
console.log(`Starting handler execution at ${new Date().toISOString()}`);
|
||||
return handler;
|
||||
},
|
||||
onAfterHandler: (result, context, startTime) => {
|
||||
const duration = performance.now() - startTime;
|
||||
console.log(`Handler executed in ${duration.toFixed(2)}ms`);
|
||||
return startTime; // Return the initial value for next execution
|
||||
}
|
||||
});
|
||||
|
||||
// Run a specific handler only once
|
||||
workflow.handle(
|
||||
[startEvent],
|
||||
runOnce((event) => {
|
||||
console.log("This handler will only run once per workflow context");
|
||||
return processEvent.with(event.data);
|
||||
})
|
||||
);
|
||||
|
||||
// Measure the execution time of this handler
|
||||
workflow.handle(
|
||||
[processEvent],
|
||||
measureTime((event) => {
|
||||
// Simulate processing time
|
||||
const start = Date.now();
|
||||
while (Date.now() - start < 100) {
|
||||
// Busy wait for 100ms
|
||||
}
|
||||
return resultEvent.with(`Processed: ${event.data}`);
|
||||
})
|
||||
);
|
||||
```
|
||||
|
||||
### Debugging with Substreams
|
||||
|
||||
You can use the `substream` feature to debug specific event flows:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, withTraceEvents } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const queryEvent = workflowEvent<string>();
|
||||
const fetchEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow with tracing
|
||||
const workflow = withTraceEvents(createWorkflow());
|
||||
|
||||
// Query handler
|
||||
workflow.handle([queryEvent], (event) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
|
||||
// Create a specific fetch event for this query
|
||||
const fetchInstance = fetchEvent.with(event.data);
|
||||
sendEvent(fetchInstance);
|
||||
|
||||
// Create a substream to only track events related to this fetch
|
||||
const substream = workflow.substream(fetchInstance, stream);
|
||||
|
||||
// Listen for results in the substream
|
||||
(async () => {
|
||||
for await (const event of substream) {
|
||||
console.log(`Event in substream: ${event.type}`);
|
||||
}
|
||||
})();
|
||||
|
||||
return resultEvent.with(`Querying: ${event.data}`);
|
||||
});
|
||||
|
||||
// Fetch handler
|
||||
workflow.handle([fetchEvent], (event) => {
|
||||
console.log(`Fetching data for: ${event.data}`);
|
||||
// Actual fetch logic would go here
|
||||
return resultEvent.with(`Results for: ${event.data}`);
|
||||
});
|
||||
```
|
||||
|
||||
## Advanced Validation and Type Safety
|
||||
|
||||
The `withValidation` middleware ensures your workflow connections are both type-safe and runtime-safe:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, withValidation } from "llamaindex";
|
||||
|
||||
// Define events with explicit types
|
||||
const inputEvent = workflowEvent<string, "input">();
|
||||
const validateEvent = workflowEvent<string, "validate">();
|
||||
const processEvent = workflowEvent<string, "process">();
|
||||
const resultEvent = workflowEvent<string, "result">();
|
||||
const errorEvent = workflowEvent<Error, "error">({
|
||||
debugLabel: "errorEvent" // Add debug labels for better error messages
|
||||
});
|
||||
|
||||
// Define the allowed event flow paths
|
||||
const workflow = withValidation(
|
||||
createWorkflow(),
|
||||
[
|
||||
[[inputEvent], [validateEvent, errorEvent]], // inputEvent can lead to validateEvent or errorEvent
|
||||
[[validateEvent], [processEvent, errorEvent]], // validateEvent can lead to processEvent or errorEvent
|
||||
[[processEvent], [resultEvent, errorEvent]], // processEvent can lead to resultEvent or errorEvent
|
||||
[[errorEvent], [resultEvent]] // errorEvent can lead to resultEvent
|
||||
]
|
||||
);
|
||||
|
||||
// Now use strictHandle to get compile-time validation
|
||||
workflow.strictHandle([inputEvent], (sendEvent, event) => {
|
||||
try {
|
||||
if (!event.data || event.data.trim().length === 0) {
|
||||
throw new Error("Empty input");
|
||||
}
|
||||
// This is allowed by our validation rules
|
||||
sendEvent(validateEvent.with(event.data.trim()));
|
||||
|
||||
// This would cause a compile-time error:
|
||||
// sendEvent(resultEvent.with("Result")); // ❌ Not allowed by validation rules
|
||||
} catch (err) {
|
||||
// This is allowed by our validation rules
|
||||
sendEvent(errorEvent.with(err instanceof Error ? err : new Error(String(err))));
|
||||
}
|
||||
});
|
||||
|
||||
// The rest of the workflow with strict validation
|
||||
workflow.strictHandle([validateEvent], (sendEvent, event) => {
|
||||
// Validation logic here
|
||||
sendEvent(processEvent.with(event.data));
|
||||
});
|
||||
|
||||
workflow.strictHandle([processEvent], (sendEvent, event) => {
|
||||
// Processing logic here
|
||||
sendEvent(resultEvent.with(`Processed: ${event.data}`));
|
||||
});
|
||||
|
||||
workflow.strictHandle([errorEvent], (sendEvent, event) => {
|
||||
// Error handling logic here
|
||||
sendEvent(resultEvent.with(`Error handled: ${event.data.message}`));
|
||||
});
|
||||
```
|
||||
|
||||
## Creating Custom Middleware
|
||||
|
||||
You can create your own middleware to extend the workflow capabilities:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// Create a logging middleware
|
||||
function withLogging(workflow) {
|
||||
const originalHandle = workflow.handle;
|
||||
|
||||
workflow.handle = function(eventTypes, handler) {
|
||||
return originalHandle.call(workflow, eventTypes, async function(...args) {
|
||||
const eventType = eventTypes.map(e => e.name || 'AnonymousEvent').join(',');
|
||||
console.log(`[${new Date().toISOString()}] Handling ${eventType}`);
|
||||
|
||||
try {
|
||||
const result = await handler(...args);
|
||||
console.log(`[${new Date().toISOString()}] Completed ${eventType}`);
|
||||
return result;
|
||||
} catch (error) {
|
||||
console.error(`[${new Date().toISOString()}] Error in ${eventType}:`, error);
|
||||
throw error;
|
||||
}
|
||||
});
|
||||
};
|
||||
|
||||
return workflow;
|
||||
}
|
||||
|
||||
// Create a retry middleware
|
||||
function withRetry(maxRetries = 3, workflow) {
|
||||
const originalHandle = workflow.handle;
|
||||
|
||||
workflow.handle = function(eventTypes, handler) {
|
||||
return originalHandle.call(workflow, eventTypes, async function(...args) {
|
||||
let lastError;
|
||||
|
||||
for (let attempt = 1; attempt <= maxRetries; attempt++) {
|
||||
try {
|
||||
return await handler(...args);
|
||||
} catch (error) {
|
||||
lastError = error;
|
||||
console.warn(`Attempt ${attempt}/${maxRetries} failed:`, error);
|
||||
|
||||
if (attempt < maxRetries) {
|
||||
// Exponential backoff
|
||||
await new Promise(resolve =>
|
||||
setTimeout(resolve, Math.pow(2, attempt - 1) * 100)
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
throw lastError;
|
||||
});
|
||||
};
|
||||
|
||||
return workflow;
|
||||
}
|
||||
|
||||
// Use the custom middleware
|
||||
const workflow = withRetry(3, withLogging(createWorkflow()));
|
||||
|
||||
// Define events
|
||||
const startEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
// Add handlers
|
||||
workflow.handle([startEvent], (event) => {
|
||||
// This handler might fail but will be retried
|
||||
if (Math.random() < 0.7) {
|
||||
throw new Error("Random failure");
|
||||
}
|
||||
return resultEvent.with(`Processed: ${event.data}`);
|
||||
});
|
||||
```
|
||||
|
||||
## Integrating with External Systems
|
||||
|
||||
You can extend your workflows to integrate with external systems:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const fetchEvent = workflowEvent<string>();
|
||||
const successEvent = workflowEvent<any>();
|
||||
const failureEvent = workflowEvent<Error>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Handle external API calls with proper error handling
|
||||
workflow.handle([fetchEvent], async (event) => {
|
||||
const { signal } = getContext();
|
||||
|
||||
try {
|
||||
// Use AbortSignal for cancellation support
|
||||
const response = await fetch(event.data, { signal });
|
||||
|
||||
if (!response.ok) {
|
||||
throw new Error(`HTTP error: ${response.status}`);
|
||||
}
|
||||
|
||||
const data = await response.json();
|
||||
return successEvent.with(data);
|
||||
} catch (error) {
|
||||
if (error.name === 'AbortError') {
|
||||
return failureEvent.with(new Error('Request was aborted'));
|
||||
}
|
||||
return failureEvent.with(error instanceof Error ? error : new Error(String(error)));
|
||||
}
|
||||
});
|
||||
|
||||
// Database integration example
|
||||
const dbQueryEvent = workflowEvent<{ collection: string; query: any }>();
|
||||
const dbResultEvent = workflowEvent<any[]>();
|
||||
|
||||
workflow.handle([dbQueryEvent], async (event) => {
|
||||
// Connect to database (pseudo-code)
|
||||
const db = await connectToDatabase();
|
||||
|
||||
try {
|
||||
const results = await db.collection(event.data.collection)
|
||||
.find(event.data.query)
|
||||
.toArray();
|
||||
|
||||
return dbResultEvent.with(results);
|
||||
} catch (error) {
|
||||
return failureEvent.with(error);
|
||||
} finally {
|
||||
await db.close();
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## Handling Complex Asynchronous Patterns
|
||||
|
||||
LlamaIndex workflows excel at managing complex asynchronous patterns:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, until, collect } from "llamaindex";
|
||||
|
||||
// Events for an orchestration workflow
|
||||
const orchestrateEvent = workflowEvent<string[]>();
|
||||
const taskEvent = workflowEvent<string>();
|
||||
const progressEvent = workflowEvent<{ task: string; progress: number }>();
|
||||
const taskCompleteEvent = workflowEvent<string>();
|
||||
const aggregateEvent = workflowEvent<any>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Orchestrator: distribute tasks and collect results
|
||||
workflow.handle([orchestrateEvent], async (event) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
const tasks = event.data;
|
||||
|
||||
// Start all tasks
|
||||
tasks.forEach(task => sendEvent(taskEvent.with(task)));
|
||||
|
||||
// Track progress
|
||||
let completed = 0;
|
||||
const results = {};
|
||||
|
||||
// Process task completion and progress events
|
||||
for await (const event of until(stream, () => completed === tasks.length)) {
|
||||
if (progressEvent.include(event)) {
|
||||
console.log(`Task ${event.data.task}: ${event.data.progress}%`);
|
||||
} else if (taskCompleteEvent.include(event)) {
|
||||
completed++;
|
||||
results[event.data] = `Completed ${event.data}`;
|
||||
console.log(`Completed ${completed}/${tasks.length} tasks`);
|
||||
}
|
||||
}
|
||||
|
||||
return aggregateEvent.with(results);
|
||||
});
|
||||
|
||||
// Task processor
|
||||
workflow.handle([taskEvent], async (event) => {
|
||||
const { sendEvent } = getContext();
|
||||
const task = event.data;
|
||||
|
||||
// Simulate task processing with progress updates
|
||||
for (let progress = 0; progress <= 100; progress += 20) {
|
||||
sendEvent(progressEvent.with({ task, progress }));
|
||||
await new Promise(resolve => setTimeout(resolve, 200));
|
||||
}
|
||||
|
||||
return taskCompleteEvent.with(task);
|
||||
});
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you've explored advanced event handling with workflows, you're ready to build sophisticated applications:
|
||||
|
||||
- [Integrating Workflows with other LlamaIndex Features](./llamaindex-integration.mdx)
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
title: Basic Workflow Patterns
|
||||
description: Learn common patterns and techniques for building effective workflows
|
||||
---
|
||||
|
||||
This guide explores common patterns you can use to build more complex workflows with workflows.
|
||||
|
||||
## Fan-out (Parallelism)
|
||||
|
||||
One of the most powerful features of workflows is the ability to run tasks in parallel:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, until, collect } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const startEvent = workflowEvent<string>();
|
||||
const processItemEvent = workflowEvent<number>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
const completeEvent = workflowEvent<string[]>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Process start event: fan out to multiple processItemEvent events
|
||||
workflow.handle([startEvent], (start) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
|
||||
// Emit multiple events to be processed in parallel
|
||||
for (let i = 0; i < 10; i++) {
|
||||
sendEvent(processItemEvent.with(i));
|
||||
}
|
||||
|
||||
// Collect all resultEvents and emit a final completeEvent
|
||||
let condition = false;
|
||||
const results = collect(
|
||||
until(stream, () => condition)
|
||||
.filter((ev) => resultEvent.includes(ev))
|
||||
);
|
||||
|
||||
return completeEvent.with(results.map(event => event.data));
|
||||
});
|
||||
|
||||
// Process each item
|
||||
workflow.handle([processItemEvent], (event) => {
|
||||
// Process the item
|
||||
const processedValue = `Processed: ${event.data}`;
|
||||
|
||||
// If this is the last item, set the condition to stop collecting
|
||||
if (event.data === 9) {
|
||||
condition = true;
|
||||
}
|
||||
|
||||
return resultEvent.with(processedValue);
|
||||
});
|
||||
```
|
||||
|
||||
This pattern allows you to:
|
||||
1. Emit multiple events to be processed in parallel
|
||||
2. Collect results as they come in
|
||||
3. Complete once all parallel tasks are finished
|
||||
|
||||
## Conditional Branching
|
||||
|
||||
You can implement conditional logic in your workflows:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
const inputEvent = workflowEvent<number>();
|
||||
const evenNumberEvent = workflowEvent<string>();
|
||||
const oddNumberEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Branch based on whether the number is even or odd
|
||||
workflow.handle([inputEvent], (event) => {
|
||||
if (event.data % 2 === 0) {
|
||||
return evenNumberEvent.with(`${event.data} is even`);
|
||||
} else {
|
||||
return oddNumberEvent.with(`${event.data} is odd`);
|
||||
}
|
||||
});
|
||||
|
||||
// Handle even numbers
|
||||
workflow.handle([evenNumberEvent], (event) => {
|
||||
return resultEvent.with(`Even result: ${event.data}`);
|
||||
});
|
||||
|
||||
// Handle odd numbers
|
||||
workflow.handle([oddNumberEvent], (event) => {
|
||||
return resultEvent.with(`Odd result: ${event.data}`);
|
||||
});
|
||||
```
|
||||
|
||||
## Using Middleware
|
||||
|
||||
LlamaIndex workflows provide middleware that can enhance your workflows:
|
||||
|
||||
### `withStore` Middleware
|
||||
|
||||
The `withStore` middleware adds a persistent store to your workflow context:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, withStore } from "llamaindex";
|
||||
|
||||
const startEvent = workflowEvent<void>();
|
||||
const incrementEvent = workflowEvent<number>();
|
||||
const resultEvent = workflowEvent<number>();
|
||||
|
||||
// Create a workflow with store middleware
|
||||
const workflow = withStore(
|
||||
() => ({
|
||||
count: 0,
|
||||
history: [] as number[],
|
||||
}),
|
||||
createWorkflow()
|
||||
);
|
||||
|
||||
// Increment the counter
|
||||
workflow.handle([startEvent], () => {
|
||||
const store = workflow.getStore();
|
||||
store.count += 1;
|
||||
store.history.push(store.count);
|
||||
return incrementEvent.with(store.count);
|
||||
});
|
||||
|
||||
// Return the current count
|
||||
workflow.handle([incrementEvent], (event) => {
|
||||
const store = workflow.getStore();
|
||||
return resultEvent.with(store.count);
|
||||
});
|
||||
```
|
||||
|
||||
### `withValidation` Middleware
|
||||
|
||||
The `withValidation` middleware adds compile-time and runtime validation to your workflows:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, withValidation } from "llamaindex";
|
||||
|
||||
const startEvent = workflowEvent<string, "start">();
|
||||
const processEvent = workflowEvent<number, "process">();
|
||||
const resultEvent = workflowEvent<string, "result">();
|
||||
const disallowedEvent = workflowEvent<void, "disallowed">();
|
||||
|
||||
// Create a workflow with validation middleware
|
||||
// Define allowed event paths
|
||||
const workflow = withValidation(
|
||||
createWorkflow(),
|
||||
[
|
||||
[[startEvent], [processEvent]], // startEvent can only lead to processEvent
|
||||
[[processEvent], [resultEvent]], // processEvent can only lead to resultEvent
|
||||
]
|
||||
);
|
||||
|
||||
// This will pass validation
|
||||
workflow.strictHandle([startEvent], (sendEvent, start) => {
|
||||
sendEvent(processEvent.with(123)); // ✅ This is allowed
|
||||
});
|
||||
|
||||
// This would fail at compile time and runtime
|
||||
workflow.strictHandle([startEvent], (sendEvent, start) => {
|
||||
// sendEvent(disallowedEvent.with()); // ❌ This would cause an error
|
||||
// sendEvent(resultEvent.with("result")); // ❌ This would also cause an error
|
||||
});
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
LlamaIndex workflows provide built-in mechanisms for handling errors:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
const startEvent = workflowEvent<string>();
|
||||
const processEvent = workflowEvent<number>();
|
||||
const errorEvent = workflowEvent<Error>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], (start) => {
|
||||
try {
|
||||
const num = Number.parseInt(start.data, 10);
|
||||
if (isNaN(num)) {
|
||||
throw new Error("Invalid number");
|
||||
}
|
||||
return processEvent.with(num);
|
||||
} catch (err) {
|
||||
return errorEvent.with(err instanceof Error ? err : new Error(String(err)));
|
||||
}
|
||||
});
|
||||
|
||||
workflow.handle([processEvent], (event) => {
|
||||
return resultEvent.with(`Result: ${event.data * 2}`);
|
||||
});
|
||||
|
||||
workflow.handle([errorEvent], (event) => {
|
||||
return resultEvent.with(`Error: ${event.data.message}`);
|
||||
});
|
||||
```
|
||||
|
||||
You can also use the signal in `getContext()` to handle errors:
|
||||
|
||||
```ts
|
||||
workflow.handle([processEvent], () => {
|
||||
const { signal } = getContext();
|
||||
|
||||
signal.onabort = () => {
|
||||
console.error("Process aborted:", signal.reason);
|
||||
// Clean up resources
|
||||
};
|
||||
|
||||
// Your processing logic here
|
||||
});
|
||||
```
|
||||
|
||||
## Connecting with Server Endpoints
|
||||
|
||||
Workflow can be used as middleware in server frameworks like Express, Hono, or Fastify:
|
||||
|
||||
```ts
|
||||
import { Hono } from "hono";
|
||||
import { serve } from "@hono/node-server";
|
||||
import { createWorkflow, workflowEvent, createHonoHandler } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const queryEvent = workflowEvent<string>();
|
||||
const responseEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([queryEvent], (event) => {
|
||||
const response = `Processed: ${event.data}`;
|
||||
return responseEvent.with(response);
|
||||
});
|
||||
|
||||
// Create Hono app
|
||||
const app = new Hono();
|
||||
|
||||
// Set up workflow endpoint
|
||||
app.post(
|
||||
"/workflow",
|
||||
createHonoHandler(
|
||||
workflow,
|
||||
async (ctx) => queryEvent.with(await ctx.req.text()),
|
||||
responseEvent
|
||||
)
|
||||
);
|
||||
|
||||
// Start server
|
||||
serve(app, ({ port }) => {
|
||||
console.log(`Server started at http://localhost:${port}`);
|
||||
});
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you've learned about basic workflow patterns, explore more advanced topics:
|
||||
- [Streaming with Workflows](./streaming.mdx)
|
||||
- [Advanced Event Handling](./advanced-events.mdx)
|
||||
+234
@@ -0,0 +1,234 @@
|
||||
---
|
||||
title: Inputs / Outputs (Outdated)
|
||||
description: This page has been replaced with newer documentation
|
||||
---
|
||||
|
||||
# ⚠️ Outdated Documentation
|
||||
|
||||
This documentation is for an older version of the workflow API. Please refer to the new llama-flow documentation:
|
||||
|
||||
- [Getting Started with llama-flow](./index.mdx)
|
||||
- [Basic Workflow Patterns](./basic-workflow.mdx)
|
||||
- [Advanced Event Handling](./advanced-events.mdx)
|
||||
|
||||
The new API provides a more lightweight and flexible approach to building workflows.
|
||||
|
||||
Inputs and outputs are the way to communicate between steps in a workflow. In the previous example,
|
||||
we used `StartEvent` and `StopEvent` to communicate between steps. However, you can use any type of event to communicate between steps.
|
||||
|
||||
## Multiple inputs
|
||||
|
||||
You can define multiple inputs for a step.
|
||||
|
||||
In the following example, we define a complex workflow with multiple inputs and outputs.
|
||||
|
||||
```ts twoslash
|
||||
import { Workflow, StartEvent, StopEvent, WorkflowEvent } from '@llamaindex/workflow';
|
||||
|
||||
class AEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class BEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class ResultEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
First, let's define the events that we will use in the workflow.
|
||||
|
||||
```ts twoslash
|
||||
import { Workflow, StartEvent, StopEvent, WorkflowEvent } from '@llamaindex/workflow';
|
||||
|
||||
class AEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class BEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class ResultEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
const workflow = new Workflow<never, string, string>();
|
||||
|
||||
workflow.addStep({
|
||||
inputs: [StartEvent<string>],
|
||||
outputs: [StopEvent<string>]
|
||||
}, async (
|
||||
context,
|
||||
startEvent
|
||||
) => {
|
||||
const input = startEvent.data;
|
||||
const aEvent = await context.requireEvent(AEvent);
|
||||
const bEvent = await context.requireEvent(BEvent);
|
||||
const a = aEvent.data;
|
||||
const b = bEvent.data;
|
||||
return new StopEvent(`Hello, ${input}! A: ${a}, B: ${b}`);
|
||||
});
|
||||
|
||||
// ---cut---
|
||||
workflow.addStep({
|
||||
inputs: [AEvent, BEvent],
|
||||
outputs: [ResultEvent]
|
||||
}, async (
|
||||
context,
|
||||
aEvent,
|
||||
bEvent
|
||||
) => {
|
||||
const a = aEvent.data;
|
||||
const b = bEvent.data;
|
||||
return new ResultEvent(`A: ${a}, B: ${b}`);
|
||||
});
|
||||
```
|
||||
|
||||
This step means that it requires two events: `AEvent` and `BEvent`. It will return a `ResultEvent` with the data `A: ${a}, B: ${b}`.
|
||||
|
||||
## A or B input
|
||||
|
||||
If we want to have a step that can accept either `AEvent` or `BEvent`, we can define the step like this:
|
||||
|
||||
```ts twoslash
|
||||
import { Workflow, StartEvent, StopEvent, WorkflowEvent } from '@llamaindex/workflow';
|
||||
|
||||
class AEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class BEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class ResultEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
const workflow = new Workflow<never, string, string>();
|
||||
|
||||
workflow.addStep({
|
||||
inputs: [StartEvent<string>],
|
||||
outputs: [StopEvent<string>]
|
||||
}, async (
|
||||
context,
|
||||
startEvent
|
||||
) => {
|
||||
const input = startEvent.data;
|
||||
const aEvent = await context.requireEvent(AEvent);
|
||||
const bEvent = await context.requireEvent(BEvent);
|
||||
const a = aEvent.data;
|
||||
const b = bEvent.data;
|
||||
return new StopEvent(`Hello, ${input}! A: ${a}, B: ${b}`);
|
||||
});
|
||||
|
||||
// ---cut---
|
||||
workflow.addStep({
|
||||
inputs: [WorkflowEvent.or(AEvent, BEvent)],
|
||||
outputs: [ResultEvent]
|
||||
}, async (
|
||||
context,
|
||||
aOrBEvent
|
||||
) => {
|
||||
if (aOrBEvent instanceof AEvent) {
|
||||
// ^?
|
||||
|
||||
|
||||
const a = aOrBEvent.data;
|
||||
// ^?
|
||||
|
||||
|
||||
return new ResultEvent(`A: ${a}`);
|
||||
} else {
|
||||
const b = aOrBEvent.data;
|
||||
// ^?
|
||||
|
||||
|
||||
return new ResultEvent(`B: ${b}`);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
This step means that it requires either `AEvent` or `BEvent`. It will return a `ResultEvent` with the data `A: ${a}` or `B: ${b}`.
|
||||
|
||||
You can still combine the logic with `context.requireEvent` to get the data from the event.
|
||||
|
||||
<Accordions>
|
||||
<Accordion title="Under the hood">
|
||||
We use JavaScript Inheritance and the prototype chain to implement the `or` logic.
|
||||
The `or` method creates a new class that extends the two classes that you pass to it.
|
||||
|
||||
<a
|
||||
target="_blank"
|
||||
href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain"
|
||||
>
|
||||
MDN - Inheritance and the prototype chain
|
||||
</a>
|
||||
</Accordion>
|
||||
</Accordions>
|
||||
|
||||
## Multiple outputs
|
||||
|
||||
You can define multiple outputs for a step.
|
||||
|
||||
```ts twoslash
|
||||
import { Workflow, StartEvent, StopEvent, WorkflowEvent } from '@llamaindex/workflow';
|
||||
|
||||
class AEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class BEvent extends WorkflowEvent<number> {
|
||||
constructor(data: number) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
class ResultEvent extends WorkflowEvent<string> {
|
||||
constructor(data: string) {
|
||||
super(data);
|
||||
}
|
||||
}
|
||||
|
||||
const workflow = new Workflow<never, string, string>();
|
||||
// ---cut---
|
||||
workflow.addStep({
|
||||
inputs: [StartEvent<string>],
|
||||
outputs: [AEvent, BEvent]
|
||||
}, async (
|
||||
context,
|
||||
startEvent
|
||||
) => {
|
||||
const input = startEvent.data;
|
||||
if (Math.random() > 0.5) {
|
||||
return new AEvent(`Hello, ${input}!`);
|
||||
} else {
|
||||
return new BEvent(42);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
This step will return either an `AEvent` or a `BEvent` based on a random number.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: Getting Started with Workflows
|
||||
description: Learn how to use LlamaIndex's lightweight workflow engine for TypeScript
|
||||
---
|
||||
|
||||
Workflows are a simple and lightweight engine for TypeScript. Built with ❤️ by LlamaIndex.
|
||||
|
||||
- Minimal core API (\<\=2kb)
|
||||
- 100% Type safe
|
||||
- Event-driven, stream oriented programming
|
||||
- Support for multiple JS runtimes/frameworks
|
||||
|
||||
## Installation
|
||||
|
||||
It's directly included with the `llamaindex` package:
|
||||
|
||||
```shell
|
||||
npm i llamaindex
|
||||
```
|
||||
|
||||
But can also be installed separately:
|
||||
|
||||
```shell
|
||||
npm i @llama-flow/core
|
||||
|
||||
# or with yarn
|
||||
yarn add @llama-flow/core
|
||||
|
||||
# or with pnpm
|
||||
pnpm add @llama-flow/core
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Events**: Data carriers that flow through the workflow
|
||||
- **Handlers**: Functions that process events and emit new events
|
||||
- **Workflow**: Connects events and handlers together
|
||||
- **Context**: Runtime environment for a workflow execution
|
||||
|
||||
## Basic Usage
|
||||
|
||||
Let's build a simple workflow that processes a text input:
|
||||
|
||||
### 1. Define events
|
||||
|
||||
First, we need to define the events that will flow through our workflow:
|
||||
|
||||
```ts
|
||||
import { workflowEvent } from "llamaindex";
|
||||
|
||||
// Define input and output events
|
||||
const startEvent = workflowEvent<string>(); // Takes a string input
|
||||
const convertEvent = workflowEvent<Number>(); // Intermediate event
|
||||
const stopEvent = workflowEvent<1 | -1>(); // Final output event, returns 1 or -1
|
||||
```
|
||||
|
||||
### 2. Create a workflow and connect events
|
||||
|
||||
Next, we'll create our workflow and define how events are processed:
|
||||
|
||||
```ts
|
||||
import { createWorkflow } from "llamaindex";
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Handle the start event: convert the string to a number
|
||||
workflow.handle([startEvent], (start) => {
|
||||
return convertEvent.with(Number.parseInt(start.data, 10));
|
||||
});
|
||||
|
||||
// Handle the convert event: determine if number is positive or negative
|
||||
workflow.handle([convertEvent], (convert) => {
|
||||
return stopEvent.with(convert.data > 0 ? 1 : -1);
|
||||
});
|
||||
```
|
||||
|
||||
### 3. Run the workflow
|
||||
|
||||
Finally, we can execute our workflow:
|
||||
|
||||
```ts
|
||||
// Create a workflow context and send the initial event
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with("42"));
|
||||
|
||||
// Process the stream to get the result
|
||||
import { pipeline } from "node:stream/promises";
|
||||
|
||||
const result = await pipeline(stream, async function (source) {
|
||||
for await (const event of source) {
|
||||
if (stopEvent.include(event)) {
|
||||
return `Result: ${event.data === 1 ? 'positive' : 'negative'}`;
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
console.log(result); // "Result: positive"
|
||||
```
|
||||
|
||||
Or using the stream utilities:
|
||||
|
||||
```ts
|
||||
import { collect, until } from "llamaindex";
|
||||
|
||||
// Collect all events until we get a stopEvent
|
||||
const allEvents = await collect(until(stream, stopEvent));
|
||||
const finalEvent = allEvents[allEvents.length - 1];
|
||||
console.log(`Result: ${finalEvent.data === 1 ? 'positive' : 'negative'}`);
|
||||
```
|
||||
|
||||
Ready to learn more? Check out our [detailed examples](./basic-workflow.mdx) to see llama-flow in action!
|
||||
@@ -0,0 +1,288 @@
|
||||
---
|
||||
title: Integrating with LlamaIndex
|
||||
description: Build AI applications by combining Workflows with other LlamaIndex features
|
||||
---
|
||||
|
||||
This guide demonstrates how to combine the power of the workflow engine with LlamaIndex's retrieval and reasoning capabilities to build sophisticated AI applications.
|
||||
|
||||
## Basic RAG Workflow
|
||||
|
||||
Let's build a simple Retrieval-Augmented Generation (RAG) workflow:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
import { Document, serviceContextFromDefaults, VectorStoreIndex } from "llamaindex";
|
||||
import { OpenAI, OpenAIEmbedding } from "@llamaindex/openai";
|
||||
import { Settings } from "@llamaindex/core/global"
|
||||
|
||||
// Define events
|
||||
const queryEvent = workflowEvent<string>();
|
||||
const retrieveEvent = workflowEvent<{ query: string; documents: Document[] }>();
|
||||
const generateEvent = workflowEvent<{ query: string; context: string }>();
|
||||
const responseEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Set default global llm
|
||||
Settings.llm = new OpenAI({
|
||||
model: "gpt-4.1-mini",
|
||||
temperature: 0.2
|
||||
});
|
||||
|
||||
// Set the default global embedModel
|
||||
Settings.embedModel = new OpenAIEmbedding({
|
||||
model: "text-embedding-3-small",
|
||||
});
|
||||
|
||||
// Sample documents
|
||||
const documents = [
|
||||
new Document({
|
||||
text: "LlamaIndex is a data framework for LLM applications to ingest, structure, and access private or domain-specific data.",
|
||||
}),
|
||||
new Document({
|
||||
text: "LlamaIndex workflows are a lightweight workflow engine for TypeScript, designed to create event-driven processes.",
|
||||
}),
|
||||
];
|
||||
|
||||
// Create vector store index
|
||||
const index = await VectorStoreIndex.fromDocuments(documents);
|
||||
|
||||
// Handle query: Retrieve relevant documents
|
||||
workflow.handle([queryEvent], (event) => {
|
||||
const query = event.data;
|
||||
console.log(`Processing query: ${query}`);
|
||||
|
||||
// Retrieve relevant documents
|
||||
const retriever = index.asRetriever();
|
||||
const nodes = retriever.retrieve(query);
|
||||
|
||||
return retrieveEvent.with({
|
||||
query,
|
||||
documents: nodes.map(node => node.node),
|
||||
});
|
||||
});
|
||||
|
||||
// Handle retrieval results: Generate response
|
||||
workflow.handle([retrieveEvent], async (event) => {
|
||||
const { query, documents } = event.data;
|
||||
|
||||
// Combine document content as context
|
||||
const context = documents.map(doc => doc.text).join('\n\n');
|
||||
|
||||
return generateEvent.with({ query, context });
|
||||
});
|
||||
|
||||
// Handle generation: Produce final response
|
||||
workflow.handle([generateEvent], async (event) => {
|
||||
const { query, context } = event.data;
|
||||
|
||||
// Create a prompt with the context and query
|
||||
const prompt = `
|
||||
Context information:
|
||||
${context}
|
||||
|
||||
Based on the context information and no other knowledge, answer the following query:
|
||||
${query}
|
||||
`;
|
||||
|
||||
// Generate response with LLM
|
||||
const response = await Settings.llm.complete({ prompt });
|
||||
|
||||
return responseEvent.with(response.text);
|
||||
});
|
||||
|
||||
// Execute the workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(queryEvent.with("What is LlamaIndex?"));
|
||||
|
||||
// Process the stream
|
||||
for await (const event of stream) {
|
||||
if (responseEvent.include(event)) {
|
||||
console.log("Final response:", event.data);
|
||||
break;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Building a Chat Application
|
||||
|
||||
Let's create a more complex chat application that maintains conversation history:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, withStore } from "llamaindex";
|
||||
import { OpenAI, OpenAIEmbedding } from "@llamaindex/openai";
|
||||
import { Document, serviceContextFromDefaults, VectorStoreIndex } from "llamaindex";
|
||||
import { Settings } from "@llamaindex/core/global"
|
||||
|
||||
// Set default global llm
|
||||
Settings.llm = new OpenAI({
|
||||
model: "gpt-4.1-mini",
|
||||
temperature: 0.2
|
||||
});
|
||||
|
||||
// Set the default global embedModel
|
||||
Settings.embedModel = new OpenAIEmbedding({
|
||||
model: "text-embedding-3-small",
|
||||
});
|
||||
|
||||
// Define store type
|
||||
type ChatStore = {
|
||||
history: Array<{ role: string; content: string }>;
|
||||
documents: Document[];
|
||||
index: VectorStoreIndex | null;
|
||||
};
|
||||
|
||||
// Define events
|
||||
const initEvent = workflowEvent<Document[]>();
|
||||
const indexCreatedEvent = workflowEvent<VectorStoreIndex>();
|
||||
const userMessageEvent = workflowEvent<string>();
|
||||
const retrievalEvent = workflowEvent<{ query: string; nodes: any[] }>();
|
||||
const responseEvent = workflowEvent<{ message: { content: string } }>();
|
||||
|
||||
// Create workflow with store
|
||||
const workflow = withStore<ChatStore>(
|
||||
() => ({
|
||||
history: [],
|
||||
documents: [],
|
||||
index: null,
|
||||
}),
|
||||
createWorkflow()
|
||||
);
|
||||
|
||||
// Initialize the chat context
|
||||
workflow.handle([initEvent], async (event) => {
|
||||
const store = workflow.getStore();
|
||||
store.documents = event.data;
|
||||
|
||||
// Create index from documents
|
||||
const index = await VectorStoreIndex.fromDocuments(store.documents);
|
||||
|
||||
store.index = index;
|
||||
return indexCreatedEvent.with(index);
|
||||
});
|
||||
|
||||
// Process user message
|
||||
workflow.handle([userMessageEvent], (event) => {
|
||||
const userMessage = event.data;
|
||||
const store = workflow.getStore();
|
||||
|
||||
// Add user message to history
|
||||
store.history.push({
|
||||
role: "user",
|
||||
content: userMessage,
|
||||
});
|
||||
|
||||
if (!store.index) {
|
||||
throw new Error("Index not initialized yet");
|
||||
}
|
||||
|
||||
// Retrieve relevant context
|
||||
const retriever = store.index.asRetriever();
|
||||
const nodes = retriever.retrieve(userMessage);
|
||||
|
||||
return retrievalEvent.with({
|
||||
query: userMessage,
|
||||
nodes,
|
||||
});
|
||||
});
|
||||
|
||||
// Generate response from retrieval results
|
||||
workflow.handle([retrievalEvent], async (event) => {
|
||||
const { query, nodes } = event.data;
|
||||
const store = workflow.getStore();
|
||||
|
||||
// Context from retrieved nodes
|
||||
const context = nodes.map(node => node.node.text).join('\n\n');
|
||||
|
||||
// Create the system message with context
|
||||
const systemMessage = {
|
||||
role: "system",
|
||||
content: `You are a helpful assistant. Use the following information to answer the user's question:
|
||||
|
||||
${context}
|
||||
|
||||
Only use the information provided above to answer. If you don't know, say so.`,
|
||||
};
|
||||
|
||||
// Create full conversation history for the chat
|
||||
const messages = [
|
||||
systemMessage,
|
||||
...store.history,
|
||||
];
|
||||
|
||||
// Generate response
|
||||
const response = await Settings.llm.chat({
|
||||
messages,
|
||||
});
|
||||
|
||||
// Add assistant response to history
|
||||
store.history.push({
|
||||
role: "assistant",
|
||||
content: response.message.content,
|
||||
});
|
||||
|
||||
return responseEvent.with(response);
|
||||
});
|
||||
|
||||
// Example usage
|
||||
async function runChat() {
|
||||
// Sample documents
|
||||
const documents = [
|
||||
new Document({
|
||||
text: "LlamaIndex is a data framework for LLM applications to ingest, structure, and access private or domain-specific data.",
|
||||
}),
|
||||
new Document({
|
||||
text: "LlamaIndex Workflows are a lightweight workflow engine for TypeScript, designed to create event-driven processes.",
|
||||
}),
|
||||
];
|
||||
|
||||
// Initialize the chat
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(initEvent.with(documents));
|
||||
|
||||
// Wait for index creation
|
||||
for await (const event of stream) {
|
||||
if (indexCreatedEvent.include(event)) {
|
||||
console.log("Index created successfully");
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
// Start conversation
|
||||
async function sendUserMessage(message: string) {
|
||||
sendEvent(userMessageEvent.with(message));
|
||||
|
||||
for await (const event of stream) {
|
||||
if (responseEvent.include(event)) {
|
||||
console.log("Assistant:", event.data.message.content);
|
||||
return event.data.message.content;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
await sendUserMessage("What is LlamaIndex?");
|
||||
await sendUserMessage("Can you tell me about LlamaIndex workflows?");
|
||||
await sendUserMessage("How might these two technologies work together?");
|
||||
}
|
||||
|
||||
runChat();
|
||||
```
|
||||
|
||||
## Building an Tool Calling Agent
|
||||
|
||||
[TODO]
|
||||
|
||||
## Conclusion
|
||||
|
||||
By combining the lightweight, event-driven workflow engine with LlamaIndex's powerful document indexing and querying capabilities, you can build sophisticated AI applications with clean, maintainable code.
|
||||
|
||||
The event-driven architecture allows you to:
|
||||
|
||||
1. Break complex processes into manageable steps
|
||||
2. Create reusable components for common AI workflows
|
||||
3. Easily debug and monitor each phase of execution
|
||||
4. Scale your applications by isolating resource-intensive steps
|
||||
5. Build more resilient systems with better error handling
|
||||
|
||||
As you build your own applications, consider how the patterns shown here can be adapted to your specific use cases.
|
||||
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"title": "Workflows",
|
||||
"description": "Event-driven workflow engine for TypeScript",
|
||||
"defaultOpen": false,
|
||||
"pages": [
|
||||
"index",
|
||||
"basic-workflow",
|
||||
"streaming",
|
||||
"advanced-events",
|
||||
"llamaindex-integration"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,371 @@
|
||||
---
|
||||
title: Streaming with Workflows
|
||||
description: Learn how to build streaming workflows
|
||||
---
|
||||
|
||||
LlamaIndex workflows are designed from the ground up to work with streaming data. The streaming capabilities make it perfect for:
|
||||
|
||||
- Building real-time applications
|
||||
- Handling large datasets incrementally
|
||||
- Creating responsive UIs that update as data becomes available
|
||||
- Implementing long-running tasks with partial results
|
||||
|
||||
## Basic Streaming
|
||||
|
||||
Every workflow context provides a stream of events:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// Define events
|
||||
const startEvent = workflowEvent<string>();
|
||||
const intermediateEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], (event) => {
|
||||
const { sendEvent } = getContext();
|
||||
|
||||
// Emit multiple intermediate events
|
||||
for (let i = 0; i < 5; i++) {
|
||||
sendEvent(intermediateEvent.with(`Progress: ${i * 20}%`));
|
||||
}
|
||||
|
||||
return resultEvent.with("Completed");
|
||||
});
|
||||
|
||||
// Run the workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with("Start processing"));
|
||||
|
||||
// Process events as they arrive
|
||||
for await (const event of stream) {
|
||||
if (intermediateEvent.include(event)) {
|
||||
console.log(event.data); // Show progress updates
|
||||
} else if (resultEvent.include(event)) {
|
||||
console.log("Final result:", event.data);
|
||||
break; // Exit the loop when done
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Using the Stream Utilities
|
||||
|
||||
Workflows provide utility functions to make working with streams easier:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent, until, collect } from "llamaindex";
|
||||
|
||||
const startEvent = workflowEvent<void>();
|
||||
const progressEvent = workflowEvent<number>();
|
||||
const resultEvent = workflowEvent<string>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], () => {
|
||||
const { sendEvent } = getContext();
|
||||
|
||||
// Emit progress events
|
||||
for (let i = 0; i < 100; i += 10) {
|
||||
sendEvent(progressEvent.with(i));
|
||||
}
|
||||
|
||||
return resultEvent.with("Complete");
|
||||
});
|
||||
|
||||
// Run the workflow and collect events until a condition is met
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with());
|
||||
|
||||
// Collect all events until resultEvent is encountered
|
||||
const events = await collect(until(stream, (event) => resultEvent.include(event)));
|
||||
|
||||
// Filter only progress events
|
||||
const progressEvents = events.filter(event => progressEvent.include(event));
|
||||
console.log(`Received ${progressEvents.length} progress updates`);
|
||||
```
|
||||
|
||||
## Conditional Stream Processing
|
||||
|
||||
You can conditionally process events and even stop the stream early:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
const startEvent = workflowEvent<number>();
|
||||
const dataEvent = workflowEvent<number>();
|
||||
const thresholdEvent = workflowEvent<void>();
|
||||
const resultEvent = workflowEvent<number[]>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], (event) => {
|
||||
const { sendEvent } = getContext();
|
||||
const max = event.data;
|
||||
|
||||
for (let i = 0; i < max; i++) {
|
||||
sendEvent(dataEvent.with(i));
|
||||
if (i >= 10) {
|
||||
// Signal that we've hit a threshold
|
||||
sendEvent(thresholdEvent.with());
|
||||
}
|
||||
}
|
||||
|
||||
return resultEvent.with(Array.from({ length: max }, (_, i) => i));
|
||||
});
|
||||
|
||||
// Run the workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with(100)); // Generate 100 numbers
|
||||
|
||||
const results = [];
|
||||
let hitThreshold = false;
|
||||
|
||||
// Process the stream
|
||||
for await (const event of stream) {
|
||||
if (dataEvent.include(event)) {
|
||||
results.push(event.data);
|
||||
} else if (thresholdEvent.include(event)) {
|
||||
hitThreshold = true;
|
||||
break; // Stop processing early
|
||||
}
|
||||
}
|
||||
|
||||
console.log(`Collected ${results.length} items before ${hitThreshold ? 'hitting threshold' : 'completion'}`);
|
||||
```
|
||||
|
||||
## Integration with UI Frameworks
|
||||
|
||||
Workflow streams can be easily integrated with UI frameworks like React to create responsive interfaces:
|
||||
|
||||
```tsx
|
||||
// In a React component
|
||||
import { useEffect, useState } from 'react';
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
function StreamingComponent() {
|
||||
const [updates, setUpdates] = useState([]);
|
||||
const [isComplete, setIsComplete] = useState(false);
|
||||
|
||||
useEffect(() => {
|
||||
// Set up workflow
|
||||
const startEvent = workflowEvent<void>();
|
||||
const updateEvent = workflowEvent<string>();
|
||||
const completeEvent = workflowEvent<void>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], () => {
|
||||
const { sendEvent } = getContext();
|
||||
|
||||
// Simulate async updates
|
||||
const intervals = [
|
||||
setTimeout(() => sendEvent(updateEvent.with("First update")), 500),
|
||||
setTimeout(() => sendEvent(updateEvent.with("Second update")), 1000),
|
||||
setTimeout(() => sendEvent(updateEvent.with("Final update")), 1500),
|
||||
setTimeout(() => sendEvent(completeEvent.with()), 2000)
|
||||
];
|
||||
|
||||
// Cleanup function
|
||||
getContext().signal.onabort = () => {
|
||||
intervals.forEach(clearTimeout);
|
||||
};
|
||||
});
|
||||
|
||||
// Run the workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with());
|
||||
|
||||
// Process events
|
||||
const processEvents = async () => {
|
||||
for await (const event of stream) {
|
||||
if (updateEvent.include(event)) {
|
||||
setUpdates(prev => [...prev, event.data]);
|
||||
} else if (completeEvent.include(event)) {
|
||||
setIsComplete(true);
|
||||
break;
|
||||
}
|
||||
}
|
||||
};
|
||||
|
||||
processEvents();
|
||||
|
||||
// Cleanup
|
||||
return () => {
|
||||
// The workflow will be aborted when the component unmounts
|
||||
};
|
||||
}, []);
|
||||
|
||||
return (
|
||||
<div>
|
||||
<h2>Streaming Updates</h2>
|
||||
<ul>
|
||||
{updates.map((update, i) => (
|
||||
<li key={i}>{update}</li>
|
||||
))}
|
||||
</ul>
|
||||
{isComplete && <div>Process complete!</div>}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Server-Sent Events (SSE)
|
||||
|
||||
Workflows are also suitable for implementing Server-Sent Events:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
import express from 'express';
|
||||
|
||||
// Define events
|
||||
const startEvent = workflowEvent<void>();
|
||||
const dataEvent = workflowEvent<string>();
|
||||
|
||||
// Create workflow
|
||||
const workflow = createWorkflow();
|
||||
|
||||
workflow.handle([startEvent], () => {
|
||||
const { sendEvent } = getContext();
|
||||
|
||||
// Send periodic updates
|
||||
const intervals = [
|
||||
setInterval(() => {
|
||||
sendEvent(dataEvent.with(`Update: ${new Date().toISOString()}`));
|
||||
}, 1000)
|
||||
];
|
||||
|
||||
// Cleanup
|
||||
getContext().signal.onabort = () => {
|
||||
intervals.forEach(clearInterval);
|
||||
};
|
||||
});
|
||||
|
||||
// Set up Express server
|
||||
const app = express();
|
||||
|
||||
app.get('/events', (req, res) => {
|
||||
// Set headers for SSE
|
||||
res.setHeader('Content-Type', 'text/event-stream');
|
||||
res.setHeader('Cache-Control', 'no-cache');
|
||||
res.setHeader('Connection', 'keep-alive');
|
||||
|
||||
// Run workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with());
|
||||
|
||||
// Handle client disconnect
|
||||
req.on('close', () => {
|
||||
// This will trigger the abort signal in the workflow
|
||||
});
|
||||
|
||||
// Process and send events
|
||||
(async () => {
|
||||
for await (const event of stream) {
|
||||
if (dataEvent.include(event)) {
|
||||
res.write(`data: ${JSON.stringify(event.data)}\n\n`);
|
||||
}
|
||||
}
|
||||
})();
|
||||
});
|
||||
|
||||
app.listen(3000, () => {
|
||||
console.log('SSE server running on port 3000');
|
||||
});
|
||||
```
|
||||
|
||||
## Advanced Techniques
|
||||
|
||||
### Flow Control
|
||||
|
||||
You can implement flow control with backpressure in your streaming workflows:
|
||||
|
||||
```ts
|
||||
import { createWorkflow, workflowEvent } from "llamaindex";
|
||||
|
||||
// This example shows how to process items with controlled concurrency
|
||||
const processItems = async (items, maxConcurrency = 3) => {
|
||||
const startEvent = workflowEvent<string[]>();
|
||||
const processItemEvent = workflowEvent<string>();
|
||||
const itemProcessedEvent = workflowEvent<string>();
|
||||
const resultEvent = workflowEvent<string[]>();
|
||||
|
||||
const workflow = createWorkflow();
|
||||
|
||||
// Handler to process individual items
|
||||
workflow.handle([processItemEvent], async (event) => {
|
||||
// Simulate processing time
|
||||
await new Promise(resolve => setTimeout(resolve, 100));
|
||||
return itemProcessedEvent.with(`Processed: ${event.data}`);
|
||||
});
|
||||
|
||||
// Main workflow handler
|
||||
workflow.handle([startEvent], async (event) => {
|
||||
const { sendEvent, stream } = getContext();
|
||||
const results = [];
|
||||
|
||||
// Process with controlled concurrency
|
||||
const items = event.data;
|
||||
let inProgress = 0;
|
||||
let itemIndex = 0;
|
||||
|
||||
// Start initial batch of items
|
||||
while (inProgress < maxConcurrency && itemIndex < items.length) {
|
||||
sendEvent(processItemEvent.with(items[itemIndex++]));
|
||||
inProgress++;
|
||||
}
|
||||
|
||||
// Process items and collect results
|
||||
for await (const event of stream) {
|
||||
if (itemProcessedEvent.include(event)) {
|
||||
results.push(event.data);
|
||||
inProgress--;
|
||||
|
||||
// Add next item if available
|
||||
if (itemIndex < items.length) {
|
||||
sendEvent(processItemEvent.with(items[itemIndex++]));
|
||||
inProgress++;
|
||||
} else if (inProgress === 0) {
|
||||
// All done
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return resultEvent.with(results);
|
||||
});
|
||||
|
||||
// Run the workflow
|
||||
const { stream, sendEvent } = workflow.createContext();
|
||||
sendEvent(startEvent.with(items));
|
||||
|
||||
// Wait for final result
|
||||
for await (const event of stream) {
|
||||
if (resultEvent.include(event)) {
|
||||
return event.data;
|
||||
}
|
||||
}
|
||||
|
||||
return [];
|
||||
};
|
||||
|
||||
// Usage
|
||||
const results = await processItems(
|
||||
Array.from({ length: 20 }, (_, i) => `Item ${i}`)
|
||||
);
|
||||
console.log(results);
|
||||
```
|
||||
|
||||
This pattern allows you to:
|
||||
1. Process large datasets without overwhelming system resources
|
||||
2. Control the level of concurrency
|
||||
3. Process data as it becomes available
|
||||
4. Create efficient data pipelines
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you've learned about streaming with workflows, explore more advanced topics:
|
||||
- [Advanced Event Handling](./advanced-events.mdx)
|
||||
- [Integration Workflows with other LlamaIndex features](./llamaindex-integration.mdx)
|
||||
@@ -1,176 +0,0 @@
|
||||
---
|
||||
title: Workflows
|
||||
---
|
||||
|
||||
A `Workflow` in LlamaIndex is a lightweight, event-driven abstraction used to chain together several events. Workflows are made up of `handlers`, with each one responsible for processing specific event types and emitting new events.
|
||||
|
||||
Workflows are designed to be flexible and can be used to build agents, RAG flows, extraction flows, or anything else you want to implement.
|
||||
|
||||
```package-install
|
||||
npm i @llamaindex/workflow @llamaindex/openai
|
||||
```
|
||||
|
||||
## Getting Started
|
||||
|
||||
Let's explore a simple workflow example where a joke is generated and then critiqued and iterated on:
|
||||
|
||||
<include cwd>../../examples/agents/workflow/joke.ts</include>
|
||||
|
||||
There are a few moving pieces here, so let's go through this step by step.
|
||||
|
||||
### Defining Workflow Events
|
||||
|
||||
```typescript
|
||||
const startEvent = workflowEvent<string>(); // Input topic for joke
|
||||
const jokeEvent = workflowEvent<{ joke: string }>(); // Intermediate joke
|
||||
const critiqueEvent = workflowEvent<{ joke: string; critique: string }>(); // Intermediate critique
|
||||
const resultEvent = workflowEvent<{ joke: string; critique: string }>(); // Final joke + critique
|
||||
```
|
||||
|
||||
Events are defined using the `workflowEvent` function and contain arbitrary data provided as a generic type. In this example, we have four events:
|
||||
- `startEvent`: Takes a string input (the joke topic)
|
||||
- `jokeEvent`: Contains an object with a joke property
|
||||
- `critiqueEvent`: Contains both the joke and its critique, used for the feedback loop
|
||||
- `resultEvent`: Contains the final joke and critique after any iterations
|
||||
|
||||
### Setting up the Workflow with Stateful Middleware
|
||||
|
||||
```typescript
|
||||
const { withState, getContext } = createStatefulMiddleware(() => ({
|
||||
numIterations: 0,
|
||||
maxIterations: 3,
|
||||
}));
|
||||
const jokeFlow = withState(createWorkflow());
|
||||
```
|
||||
|
||||
Our workflow is implemented using the `createWorkflow()` function, enhanced with the `withState` middleware. This middleware provides shared state across all handlers, which in this case tracks:
|
||||
- `numIterations`: Counts how many iterations of joke improvement we've done
|
||||
- `maxIterations`: Sets a limit to prevent infinite loops
|
||||
|
||||
This state will be accessible within workflows by using the `getContext().state` function.
|
||||
|
||||
### Adding Handlers with Loops
|
||||
|
||||
We have three key handlers in our workflow:
|
||||
|
||||
1. The first handler processes the `startEvent`, generates an initial joke, and emits a `jokeEvent`:
|
||||
|
||||
```typescript
|
||||
jokeFlow.handle([startEvent], async (event) => {
|
||||
// Prompt the LLM to write a joke
|
||||
const prompt = `Write your best joke about ${event.data}. Write the joke between <joke> and </joke> tags.`;
|
||||
const response = await llm.complete({ prompt });
|
||||
|
||||
// Parse the joke from the response
|
||||
const joke =
|
||||
response.text.match(/<joke>([\s\S]*?)<\/joke>/)?.[1]?.trim() ??
|
||||
response.text;
|
||||
return jokeEvent.with({ joke: joke });
|
||||
});
|
||||
```
|
||||
|
||||
2. The second handler handles the `jokeEvent`, critiques the joke, and either:
|
||||
- Emits a `critiqueEvent` if the joke needs improvement
|
||||
- Emits a `resultEvent` if the joke is good enough
|
||||
|
||||
```typescript
|
||||
jokeFlow.handle([jokeEvent], async (event) => {
|
||||
// Prompt the LLM to critique the joke
|
||||
const prompt = `Give a thorough critique of the following joke. If the joke needs improvement, put "IMPROVE" somewhere in the critique: ${event.data.joke}`;
|
||||
const response = await llm.complete({ prompt });
|
||||
|
||||
// If the critique includes "IMPROVE", keep iterating, else, return the result
|
||||
if (response.text.includes("IMPROVE")) {
|
||||
return critiqueEvent.with({
|
||||
joke: event.data.joke,
|
||||
critique: response.text,
|
||||
});
|
||||
}
|
||||
|
||||
return resultEvent.with({ joke: event.data.joke, critique: response.text });
|
||||
});
|
||||
```
|
||||
|
||||
3. The third handler processes the `critiqueEvent`, generates an improved joke based on the critique, and either:
|
||||
- Loops back to the joke evaluation (if under the iteration limit)
|
||||
- Emits the final `resultEvent` (if iteration limit reached)
|
||||
|
||||
```typescript
|
||||
jokeFlow.handle([critiqueEvent], async (event) => {
|
||||
// Keep track of the number of iterations
|
||||
const state = getContext().state;
|
||||
state.numIterations++;
|
||||
|
||||
// Write a new joke based on the previous joke and critique
|
||||
const prompt = `Write a new joke based on the following critique and the original joke. Write the joke between <joke> and </joke> tags.\n\nJoke: ${event.data.joke}\n\nCritique: ${event.data.critique}`;
|
||||
const response = await llm.complete({ prompt });
|
||||
|
||||
// Parse the joke from the response
|
||||
const joke =
|
||||
response.text.match(/<joke>([\s\S]*?)<\/joke>/)?.[1]?.trim() ??
|
||||
response.text;
|
||||
|
||||
// If we've done less than the max number of iterations, keep iterating
|
||||
// else, return the result
|
||||
if (state.numIterations < state.maxIterations) {
|
||||
return jokeEvent.with({ joke: joke });
|
||||
}
|
||||
|
||||
return resultEvent.with({ joke: joke, critique: event.data.critique });
|
||||
});
|
||||
```
|
||||
|
||||
### Running the Workflow
|
||||
|
||||
```typescript
|
||||
async function main() {
|
||||
const { stream, sendEvent } = jokeFlow.createContext();
|
||||
sendEvent(startEvent.with("pirates"));
|
||||
|
||||
let result: { joke: string, critique: string } | undefined;
|
||||
|
||||
for await (const event of stream) {
|
||||
// console.log(event.data); optionally log the event data
|
||||
if (resultEvent.include(event)) {
|
||||
result = event.data;
|
||||
break; // Stop when we get the final result
|
||||
}
|
||||
}
|
||||
|
||||
console.log(result);
|
||||
}
|
||||
```
|
||||
|
||||
To run the workflow, we:
|
||||
1. Create a workflow context with `createContext()`
|
||||
2. Trigger the initial event with `sendEvent()`
|
||||
3. Listen to the event stream and process events as they arrive
|
||||
4. Use `include()` to check if an event is of a specific type
|
||||
5. Break the loop when we receive our final result
|
||||
|
||||
### Using Stream Utilities
|
||||
|
||||
The `stream` returned by `createContext` contains utility functions to make working with event streams easier:
|
||||
|
||||
```typescript
|
||||
// Create a workflow context and send the initial event
|
||||
const { stream, sendEvent } = jokeFlow.createContext();
|
||||
sendEvent(startEvent.with("pirates"));
|
||||
|
||||
// Collect all events until we get a resultEvent
|
||||
const allEvents = await stream.until(resultEvent).toArray();
|
||||
|
||||
// The last event will be the resultEvent
|
||||
const finalEvent = allEvents.at(-1);
|
||||
console.log(finalEvent.data); // Output the joke and critique
|
||||
```
|
||||
|
||||
The stream utilities make it easier to work with the asynchronous event flow. In this example, we use:
|
||||
- `toArray`: Aggregates all events into an array
|
||||
- `until`: Creates a stream that emits events until a condition is met (in this case, until a resultEvent is received)
|
||||
|
||||
You can combine these utilities with other stream operators like `filter` and `map` to create powerful processing pipelines.
|
||||
|
||||
## Next Steps
|
||||
|
||||
To learn more about workflows, check out [the Workflows documentation](/docs/llamaindex/modules/agents/workflows).
|
||||
@@ -1,3 +1,3 @@
|
||||
{
|
||||
"pages": ["llamaindex", "api", "llamaflow", "chat-ui"]
|
||||
"pages": ["llamaindex", "llamaflow", "cloud", "api"]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
export type {
|
||||
HandlerContext,
|
||||
Workflow,
|
||||
WorkflowContext,
|
||||
} from "@llamaindex/workflow";
|
||||
+2
-10
@@ -3,20 +3,12 @@
|
||||
"extends": ["//"],
|
||||
"tasks": {
|
||||
"build": {
|
||||
"inputs": [
|
||||
"node_modules/@llama-flow/docs/**",
|
||||
"node_modules/@llamaindex/chat-ui-docs/**",
|
||||
"src/**/*.ts",
|
||||
"src/**/*.tsx",
|
||||
"src/**/*.mdx",
|
||||
"src/**/*.md"
|
||||
],
|
||||
"outputs": [
|
||||
".next",
|
||||
".source",
|
||||
"next-env.d.ts",
|
||||
"src/content/docs/api/**",
|
||||
"tsconfig.json"
|
||||
"src/content/docs/cloud/api/**",
|
||||
"src/content/docs/api/**"
|
||||
],
|
||||
"env": [
|
||||
"LLAMA_CLOUD_API_KEY",
|
||||
|
||||
@@ -2,10 +2,12 @@
|
||||
"plugin": ["typedoc-plugin-markdown", "typedoc-plugin-merge-modules"],
|
||||
"entryPoints": [
|
||||
"../../packages/{,**/}index.ts",
|
||||
"../../packages/readers/src/*.ts"
|
||||
"../../packages/readers/src/*.ts",
|
||||
"../../packages/cloud/src/{reader,utils}.ts"
|
||||
],
|
||||
"exclude": [
|
||||
"../../packages/autotool/**/src/index.ts",
|
||||
"../../packages/cloud/src/client/index.ts",
|
||||
"**/node_modules/**",
|
||||
"**/dist/**",
|
||||
"**/test/**",
|
||||
@@ -20,7 +22,7 @@
|
||||
"categoryOrder": ["Classes", "Enums", "Functions", "Interfaces", "Types"],
|
||||
"sort": ["source-order"],
|
||||
"entryFileName": "index.md",
|
||||
"fileExtension": ".md",
|
||||
"fileExtension": ".mdx",
|
||||
"hidePageTitle": true,
|
||||
"hidePageHeader": true,
|
||||
"hideGroupHeadings": true,
|
||||
|
||||
@@ -1,19 +1,5 @@
|
||||
# @llamaindex/core-e2e
|
||||
|
||||
## 0.1.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- b0cd530: # Breaking Change
|
||||
|
||||
## What Changed
|
||||
|
||||
Remove default setting of llm and embedModel in Settings
|
||||
|
||||
## Migration Guide
|
||||
|
||||
Set the llm provider and embed Model in the top of your code using Settings.llm = and Settings.embedModel
|
||||
|
||||
## 0.1.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
-135
@@ -1,135 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaIndexTS e2e testing package.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/e2e` package contains end-to-end tests and examples for LlamaIndexTS, ensuring the library works correctly across different runtime environments and use cases. It validates integration between core packages, providers, and real-world usage scenarios.
|
||||
|
||||
## Development Commands
|
||||
|
||||
Run e2e tests from the root directory using:
|
||||
|
||||
- `pnpm e2e` - Run all e2e tests with mocked LLM responses
|
||||
- `pnpm e2e:nomock` - Run e2e tests with real API calls (requires API keys)
|
||||
|
||||
Local e2e package commands:
|
||||
|
||||
- `npm run e2e` - Run all e2e tests with mock register
|
||||
- `npm run e2e:nomock` - Run tests without mocking (real API calls)
|
||||
- `npm run e2e:updatesnap` - Update test snapshots
|
||||
|
||||
## Testing Structure
|
||||
|
||||
### Core Test Files (`node/`)
|
||||
|
||||
**Main Test Suites:**
|
||||
|
||||
- `smoke.e2e.ts` - CJS/ESM dual module compatibility tests and basic import validation
|
||||
- `openai.e2e.ts` - OpenAI provider integration tests (LLM, agents, tools)
|
||||
- `claude.e2e.ts` - Anthropic Claude provider tests
|
||||
- `ollama.e2e.ts` - Ollama local LLM provider tests
|
||||
- `react.e2e.ts` - ReAct agent framework tests
|
||||
- `issue.e2e.ts` - Regression tests for specific GitHub issues
|
||||
|
||||
**Specialized Tests:**
|
||||
|
||||
- `embedding/clip.e2e.ts` - CLIP embedding model tests
|
||||
- `vector-store/` - Vector database integration tests (Pinecone, PostgreSQL with pgvector)
|
||||
|
||||
### Test Utilities
|
||||
|
||||
- `utils.ts` - Common test utilities and helper functions
|
||||
- `fixtures/` - Test data and mock tool definitions
|
||||
- `snapshot/` - Stored test snapshots for regression testing
|
||||
- `mock-register.js` & `mock-module.js` - LLM response mocking system
|
||||
|
||||
### Examples Directory (`examples/`)
|
||||
|
||||
Runtime-specific example applications that serve as integration tests:
|
||||
|
||||
**Edge/Serverless Runtimes:**
|
||||
|
||||
- `cloudflare-worker-agent/` - Cloudflare Workers agent example with Vitest
|
||||
- `cloudflare-hono/` - Cloudflare Workers with Hono framework
|
||||
- `nextjs-edge-runtime/` - Next.js Edge Runtime compatibility
|
||||
- `nextjs-node-runtime/` - Next.js Node.js runtime example
|
||||
- `nextjs-agent/` - Next.js with agent integration
|
||||
|
||||
**Client-Side:**
|
||||
|
||||
- `llama-parse-browser/` - Browser-based LlamaParse integration
|
||||
- `vite-import-llamaindex/` - Vite bundler compatibility test
|
||||
|
||||
**Alternative Frameworks:**
|
||||
|
||||
- `waku-query-engine/` - Waku framework with query engine integration
|
||||
|
||||
## Testing Patterns
|
||||
|
||||
### Mock System
|
||||
|
||||
The e2e tests use a sophisticated mocking system for consistent testing:
|
||||
|
||||
- **Mock Register**: `mock-register.js` enables LLM response mocking
|
||||
- **Snapshot Testing**: Pre-recorded responses stored in `snapshot/` directory
|
||||
- **Real API Mode**: Tests can run against real APIs when `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, etc. are provided
|
||||
|
||||
### Test Categories
|
||||
|
||||
1. **Smoke Tests**: Basic import/export validation and dual module (CJS/ESM) compatibility
|
||||
2. **Provider Integration**: LLM provider functionality (chat, streaming, function calling)
|
||||
3. **Agent Tests**: Agent framework validation with tool calling and reasoning
|
||||
4. **Runtime Compatibility**: Cross-platform runtime environment testing
|
||||
5. **Regression Tests**: Issue-specific tests preventing regressions
|
||||
|
||||
### Environment Conditions
|
||||
|
||||
Tests validate multiple JavaScript runtime conditions:
|
||||
|
||||
- `edge-light` - Vercel Edge Runtime
|
||||
- `workerd` - Cloudflare Workers runtime
|
||||
- `react-server` - React Server Components environment
|
||||
|
||||
## Dependencies
|
||||
|
||||
The package includes comprehensive workspace dependencies for testing all major LlamaIndexTS features:
|
||||
|
||||
**Core Dependencies:**
|
||||
|
||||
- `@llamaindex/core` - Base abstractions
|
||||
- `@llamaindex/env` - Runtime environment compatibility
|
||||
- `llamaindex` - Main package
|
||||
|
||||
**Provider Dependencies:**
|
||||
|
||||
- `@llamaindex/openai` - OpenAI integration
|
||||
- `@llamaindex/anthropic` - Anthropic Claude integration
|
||||
- `@llamaindex/ollama` - Ollama local LLM support
|
||||
- `@llamaindex/clip` - CLIP embedding models
|
||||
- `@llamaindex/pinecone` - Pinecone vector store
|
||||
- `@llamaindex/postgres` - PostgreSQL with pgvector
|
||||
|
||||
**Testing Utilities:**
|
||||
|
||||
- `@faker-js/faker` - Test data generation
|
||||
- `@huggingface/transformers` - Local model support
|
||||
- `consola` - Logging in tests
|
||||
- `dotenv` - Environment variable management
|
||||
- `tsx` - TypeScript execution for Node.js
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Build Dependency**: E2E tests depend on build artifacts, so always run `pnpm build` before testing
|
||||
- **API Keys**: Real API testing requires environment variables (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, etc.)
|
||||
- **Snapshot Updates**: Use `npm run e2e:updatesnap` to update test snapshots after intentional changes
|
||||
- **Mock vs Real**: Use mock mode for CI/fast development, real mode for integration validation
|
||||
- **Runtime Testing**: Examples serve dual purpose as integration tests and usage documentation
|
||||
- **Node.js Test Runner**: Uses built-in Node.js test runner with tsx for TypeScript support
|
||||
|
||||
## Common Workflows
|
||||
|
||||
1. **Adding New Provider**: Create test file in `node/`, add mock snapshots, validate across runtimes
|
||||
2. **Runtime Compatibility**: Add example in `examples/` with framework-specific testing setup
|
||||
3. **Regression Testing**: Add specific test case in `issue.e2e.ts` with GitHub issue reference
|
||||
4. **Mock Updates**: Update snapshots when LLM provider responses change intentionally
|
||||
@@ -1,156 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaIndexTS Cloudflare Workers + Hono example.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/cloudflare-hono` package is an end-to-end example demonstrating how to use LlamaIndexTS in a Cloudflare Workers environment with the Hono web framework. This example showcases building an AI agent with vector search capabilities that runs on Cloudflare's edge runtime.
|
||||
|
||||
## Development Commands
|
||||
|
||||
- `npm run dev` or `npm start` - Start local development server with Wrangler
|
||||
- `npm run build` - Build for deployment (dry run to dist directory)
|
||||
- `npm run deploy` - Deploy to Cloudflare Workers
|
||||
- `npm run cf-typegen` - Generate TypeScript types for Cloudflare Workers
|
||||
|
||||
## Architecture
|
||||
|
||||
This example demonstrates a complete RAG (Retrieval-Augmented Generation) system running on Cloudflare Workers:
|
||||
|
||||
### Key Components
|
||||
|
||||
1. **Hono Framework**: Lightweight web framework optimized for edge runtimes
|
||||
2. **OpenAI Integration**: GPT-4o-mini for language model and text-embedding-3-small for embeddings
|
||||
3. **Pinecone Vector Store**: Cloud vector database for document storage and retrieval
|
||||
4. **OpenAI Agent**: Function-calling agent with tool integration
|
||||
5. **Query Engine Tool**: Business information retrieval tool
|
||||
|
||||
### Request Flow
|
||||
|
||||
1. POST request to `/llm` endpoint with `{ message: "user question" }`
|
||||
2. Environment setup using `@llamaindex/env` for Cloudflare Workers compatibility
|
||||
3. Dynamic imports for tree-shaking and edge runtime optimization
|
||||
4. LLM and embedding model configuration with API keys from environment
|
||||
5. Vector store connection to Pinecone with predefined namespace
|
||||
6. Vector index creation and retriever setup (top-k=3 similarity search)
|
||||
7. Query engine tool creation for business information retrieval
|
||||
8. OpenAI agent initialization with tools
|
||||
9. Agent chat execution and response extraction
|
||||
|
||||
### Runtime Optimizations
|
||||
|
||||
- **Dynamic Imports**: All LlamaIndex packages imported asynchronously for optimal cold start performance
|
||||
- **Environment Setup**: Uses `@llamaindex/env` package for Cloudflare Workers compatibility
|
||||
- **Tree Shaking**: Selective imports reduce bundle size for edge deployment
|
||||
- **Async Operations**: Fully async pipeline optimized for serverless execution
|
||||
|
||||
## Configuration
|
||||
|
||||
### Wrangler Configuration (`wrangler.toml`)
|
||||
|
||||
- **Runtime**: Cloudflare Workers with Node.js AsyncLocalStorage compatibility
|
||||
- **Compatibility Date**: 2024-11-12 with `nodejs_als` flag
|
||||
- **Observability**: Enabled for monitoring and debugging
|
||||
- **Entry Point**: `src/index.ts`
|
||||
|
||||
### TypeScript Configuration
|
||||
|
||||
- **Target**: ES2021 for modern JavaScript features
|
||||
- **Module**: ES2022 with bundler module resolution
|
||||
- **Types**: Cloudflare Workers types for runtime compatibility
|
||||
- **Strict Mode**: Enabled for type safety
|
||||
|
||||
### Environment Variables
|
||||
|
||||
Required Cloudflare Workers environment variables:
|
||||
|
||||
- `OPENAI_API_KEY` - OpenAI API access for LLM and embeddings
|
||||
- `PINECONE_API_KEY` - Pinecone vector database access
|
||||
|
||||
## Dependencies
|
||||
|
||||
### Runtime Dependencies
|
||||
|
||||
- `hono` - Lightweight web framework for edge runtimes
|
||||
|
||||
### Development Dependencies
|
||||
|
||||
- `@cloudflare/workers-types` - TypeScript definitions for Cloudflare Workers
|
||||
- `wrangler` - Cloudflare Workers CLI and development server
|
||||
- `typescript` - TypeScript compiler
|
||||
|
||||
### LlamaIndexTS Integration
|
||||
|
||||
This example relies on workspace dependencies:
|
||||
|
||||
- `llamaindex` - Core LlamaIndexTS functionality
|
||||
- `@llamaindex/openai` - OpenAI provider (LLM, embeddings, agents)
|
||||
- `@llamaindex/pinecone` - Pinecone vector store integration
|
||||
- `@llamaindex/env` - Runtime environment compatibility layer
|
||||
|
||||
## Code Patterns
|
||||
|
||||
### Environment Setup Pattern
|
||||
|
||||
```typescript
|
||||
const { setEnvs } = await import("@llamaindex/env");
|
||||
setEnvs(c.env);
|
||||
```
|
||||
|
||||
Required first step for Cloudflare Workers compatibility.
|
||||
|
||||
### Dynamic Import Pattern
|
||||
|
||||
```typescript
|
||||
const { VectorStoreIndex, Settings } = await import("llamaindex");
|
||||
const { OpenAI, OpenAIAgent } = await import("@llamaindex/openai");
|
||||
```
|
||||
|
||||
Optimizes bundle size and cold start performance.
|
||||
|
||||
### Settings Configuration
|
||||
|
||||
```typescript
|
||||
Settings.llm = new OpenAI({ model: "gpt-4o-mini" });
|
||||
Settings.embedModel = new OpenAIEmbedding({ model: "text-embedding-3-small" });
|
||||
Settings.nodeParser = new SentenceSplitter({ chunkSize: 8191 });
|
||||
```
|
||||
|
||||
Global configuration for consistent LLM behavior.
|
||||
|
||||
### Agent Tool Integration
|
||||
|
||||
```typescript
|
||||
const tools = [
|
||||
new QueryEngineTool({ queryEngine, metadata: { name, description } }),
|
||||
];
|
||||
const agent = new OpenAIAgent({ tools });
|
||||
```
|
||||
|
||||
Function-calling agent with domain-specific tools.
|
||||
|
||||
## Usage
|
||||
|
||||
1. **Local Development**: Run `npm run dev` to start Wrangler development server
|
||||
2. **Environment Setup**: Configure `OPENAI_API_KEY` and `PINECONE_API_KEY` in Wrangler
|
||||
3. **API Testing**: POST to `/llm` with JSON payload `{ message: "your question" }`
|
||||
4. **Deployment**: Run `npm run deploy` to publish to Cloudflare Workers
|
||||
|
||||
## Integration Testing
|
||||
|
||||
This example serves as an integration test for:
|
||||
|
||||
- Cloudflare Workers runtime compatibility
|
||||
- Hono framework integration
|
||||
- OpenAI provider functionality
|
||||
- Pinecone vector store operations
|
||||
- Agent workflow execution
|
||||
- Dynamic import optimization
|
||||
- Environment variable handling
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
- **Cold Start**: Dynamic imports minimize initial bundle size
|
||||
- **Memory Usage**: Efficient vector operations with Pinecone cloud storage
|
||||
- **Latency**: Edge deployment reduces geographic latency
|
||||
- **Concurrency**: Serverless architecture handles concurrent requests efficiently
|
||||
@@ -1,77 +1,5 @@
|
||||
# @llamaindex/cloudflare-worker-agent-test
|
||||
|
||||
## 0.0.166
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
|
||||
## 0.0.165
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.4
|
||||
|
||||
## 0.0.164
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.0.163
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.2
|
||||
|
||||
## 0.0.162
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.0.161
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
|
||||
## 0.0.160
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.6
|
||||
|
||||
## 0.0.159
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.5
|
||||
|
||||
## 0.0.158
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.0.157
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
|
||||
## 0.0.156
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.0.155
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,127 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the Cloudflare Worker Agent example in the LlamaIndexTS e2e testing suite.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/cloudflare-worker-agent-test` package demonstrates how to use LlamaIndex.TS within a Cloudflare Worker environment. This example serves as both a functional integration test and a reference implementation for deploying AI agents on Cloudflare's edge platform.
|
||||
|
||||
## Development Commands
|
||||
|
||||
Local development and testing:
|
||||
|
||||
- `npm run dev` or `npm start` - Start Wrangler development server
|
||||
- `npm run build` - Build worker for deployment (dry-run with output to dist/)
|
||||
- `npm run deploy` - Deploy worker to Cloudflare
|
||||
- `npm run test` - Run Vitest tests using Cloudflare Workers test environment
|
||||
- `npm run cf-typegen` - Generate TypeScript types from wrangler.toml bindings
|
||||
|
||||
## Architecture
|
||||
|
||||
### Worker Implementation (`src/index.ts`)
|
||||
|
||||
The worker implements a basic HTTP handler that:
|
||||
|
||||
1. **Environment Setup**: Uses `@llamaindex/env` to configure runtime environment variables
|
||||
2. **Agent Initialization**: Creates an OpenAI agent with streaming support
|
||||
3. **Request Processing**: Accepts text input via HTTP request body
|
||||
4. **Streaming Response**: Returns streaming AI responses (though currently returns static "Hello, world!")
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- Environment interface with `OPENAI_API_KEY` requirement
|
||||
- Dynamic imports for optimal bundle size (`@llamaindex/env`, `@llamaindex/openai`)
|
||||
- OpenAI agent with streaming chat capability
|
||||
- Transform stream for encoding chat response deltas
|
||||
|
||||
### Configuration Files
|
||||
|
||||
**Wrangler Configuration (`wrangler.toml`):**
|
||||
|
||||
- Worker name: "agent"
|
||||
- Entry point: `src/index.ts`
|
||||
- Compatibility date: 2024-04-23
|
||||
- Node.js compatibility enabled via `nodejs_compat` flag
|
||||
- Commented examples for all major Cloudflare Worker bindings (D1, KV, R2, etc.)
|
||||
|
||||
**TypeScript Configuration (`tsconfig.json`):**
|
||||
|
||||
- Target: ES2021 with ES2022 modules
|
||||
- Bundler module resolution for Cloudflare Workers
|
||||
- Cloudflare Workers types included (`@cloudflare/workers-types/2023-07-01`)
|
||||
- Isolated modules enabled for edge runtime compatibility
|
||||
|
||||
### Testing Setup
|
||||
|
||||
**Vitest Configuration (`vitest.config.ts`):**
|
||||
|
||||
- Uses `@cloudflare/vitest-pool-workers` for Cloudflare Workers testing environment
|
||||
- Integrates with wrangler.toml configuration
|
||||
- Enables testing in actual Workers runtime conditions
|
||||
|
||||
**Test Implementation (`test/index.spec.ts`):**
|
||||
|
||||
- Unit-style testing with Cloudflare Workers test utilities
|
||||
- Mock environment variables (OPENAI_API_KEY)
|
||||
- Uses `createExecutionContext()` and `waitOnExecutionContext()` for proper async testing
|
||||
- Currently marked as failing due to implementation bug (returns "Hello World!" instead of actual agent response)
|
||||
|
||||
## Runtime Environment
|
||||
|
||||
### Cloudflare Workers Compatibility
|
||||
|
||||
This example demonstrates LlamaIndex.TS compatibility with the Cloudflare Workers runtime (`workerd`):
|
||||
|
||||
- **Edge Runtime**: Runs on Cloudflare's global edge network
|
||||
- **Node.js Compatibility**: Uses `nodejs_compat` flag for Node.js APIs
|
||||
- **Module System**: ESM-only with dynamic imports for code splitting
|
||||
- **Environment Variables**: Secure handling via Cloudflare Workers environment bindings
|
||||
|
||||
### Key Dependencies
|
||||
|
||||
- `llamaindex` (workspace) - Main LlamaIndex.TS package
|
||||
- `@cloudflare/workers-types` - TypeScript definitions for Workers APIs
|
||||
- `@cloudflare/vitest-pool-workers` - Testing framework for Workers environment
|
||||
- `wrangler` - Cloudflare Workers CLI and build tool
|
||||
|
||||
## Development Notes
|
||||
|
||||
### Environment Variables
|
||||
|
||||
- Create `.dev.vars` file with `OPENAI_API_KEY=your_key_here` for local development
|
||||
- Production secrets managed via `wrangler secret put OPENAI_API_KEY`
|
||||
|
||||
### Known Issues
|
||||
|
||||
- **Response Bug**: Worker currently returns static "Hello, world!" instead of streaming agent response (line 34 in `src/index.ts`)
|
||||
- **Test Status**: Main test marked as `.fails()` due to above implementation issue
|
||||
|
||||
### Bundle Optimization
|
||||
|
||||
- Uses dynamic imports to enable code splitting and reduce initial bundle size
|
||||
- Critical for Cloudflare Workers size limits and cold start performance
|
||||
- Environment setup (`@llamaindex/env`) imported dynamically to defer execution
|
||||
|
||||
### Security Considerations
|
||||
|
||||
- API keys handled through Cloudflare Workers environment bindings
|
||||
- No sensitive data stored in source code
|
||||
- Secure environment variable access pattern using `env` parameter
|
||||
|
||||
## Common Workflows
|
||||
|
||||
1. **Local Development**: Use `npm run dev` with `.dev.vars` file for API keys
|
||||
2. **Testing**: Run `npm test` to validate Workers runtime compatibility
|
||||
3. **Deployment**: Use `npm run deploy` after configuring production secrets
|
||||
4. **Debugging**: Use `wrangler tail` to view production logs and errors
|
||||
5. **Type Generation**: Run `npm run cf-typegen` after modifying wrangler.toml bindings
|
||||
|
||||
## Integration Testing Purpose
|
||||
|
||||
This example serves multiple purposes in the e2e test suite:
|
||||
|
||||
- **Runtime Validation**: Ensures LlamaIndex.TS works in Cloudflare Workers environment
|
||||
- **Bundle Testing**: Validates that dynamic imports and code splitting work correctly
|
||||
- **API Integration**: Tests OpenAI provider integration in edge runtime
|
||||
- **Streaming Support**: Demonstrates streaming response handling in Workers
|
||||
- **Reference Implementation**: Provides template for real-world Cloudflare Workers deployments
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@llamaindex/cloudflare-worker-agent-test",
|
||||
"version": "0.0.166",
|
||||
"version": "0.0.155",
|
||||
"type": "module",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
|
||||
@@ -1,69 +1,5 @@
|
||||
# @llamaindex/llama-parse-browser-test
|
||||
|
||||
## 0.0.68
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.13
|
||||
|
||||
## 0.0.67
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.12
|
||||
|
||||
## 0.0.66
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [76ff23d]
|
||||
- @llamaindex/cloud@4.0.11
|
||||
|
||||
## 0.0.65
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.10
|
||||
|
||||
## 0.0.64
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3703f90]
|
||||
- @llamaindex/cloud@4.0.9
|
||||
|
||||
## 0.0.63
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.8
|
||||
|
||||
## 0.0.62
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [40f5f41]
|
||||
- @llamaindex/cloud@4.0.7
|
||||
|
||||
## 0.0.61
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.6
|
||||
|
||||
## 0.0.60
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- @llamaindex/cloud@4.0.5
|
||||
|
||||
## 0.0.59
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/cloud@4.0.4
|
||||
|
||||
## 0.0.58
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,111 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaParse Browser Test example.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/llama-parse-browser-test` package is a minimal browser-based example that demonstrates how to use LlamaParse (from `@llamaindex/cloud`) in a web browser environment. This serves as both an integration test and a reference implementation for browser compatibility with LlamaIndexTS cloud services.
|
||||
|
||||
## Purpose
|
||||
|
||||
This example validates that:
|
||||
|
||||
- `@llamaindex/cloud` package works correctly in browser environments
|
||||
- LlamaParse functionality can be bundled and run in web applications
|
||||
- The build process properly handles WASM dependencies and browser-specific requirements
|
||||
- TypeScript compilation works with DOM APIs and modern bundler tooling
|
||||
|
||||
## Development Commands
|
||||
|
||||
- `npm run dev` - Start Vite development server with hot reload
|
||||
- `npm run build` - Build for production (TypeScript compilation + Vite build)
|
||||
- `npm run preview` - Preview the production build locally
|
||||
|
||||
## Architecture
|
||||
|
||||
### Build Setup
|
||||
|
||||
**Bundler**: Vite 6.x with TypeScript support
|
||||
**WASM Support**: Uses `vite-plugin-wasm` for WebAssembly module handling
|
||||
**Module System**: ESM-only (`"type": "module"`)
|
||||
**Target Environment**: Modern browsers (ES2020+)
|
||||
|
||||
### Key Configuration
|
||||
|
||||
**Vite Config (`vite.config.ts`):**
|
||||
|
||||
- `vite-plugin-wasm` - Enables WASM module imports
|
||||
- `ssr.external: ["tiktoken"]` - Excludes tiktoken from SSR bundling (browser-only)
|
||||
|
||||
**TypeScript Config (`tsconfig.json`):**
|
||||
|
||||
- Extends root monorepo TypeScript configuration
|
||||
- DOM and DOM.Iterable libraries enabled for browser APIs
|
||||
- Bundler module resolution for optimal Vite integration
|
||||
- References `@llamaindex/cloud` package for type checking
|
||||
|
||||
### Application Structure
|
||||
|
||||
**Entry Point (`src/main.ts`):**
|
||||
|
||||
- Imports `LlamaParseReader` from `@llamaindex/cloud`
|
||||
- Instantiates the reader to test browser compatibility
|
||||
- Minimal DOM manipulation for visual feedback
|
||||
|
||||
**Styling (`src/style.css`):**
|
||||
|
||||
- Modern CSS with light/dark theme support
|
||||
- Responsive design with flexbox layout
|
||||
- Clean, minimal UI suitable for testing environment
|
||||
|
||||
**HTML (`index.html`):**
|
||||
|
||||
- Standard Vite HTML template
|
||||
- Single-page application structure
|
||||
- Module script loading for ES6 imports
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Core Dependency:**
|
||||
|
||||
- `@llamaindex/cloud` (workspace) - LlamaCloud integration including LlamaParse
|
||||
|
||||
**Development Dependencies:**
|
||||
|
||||
- `vite` - Modern build tool and development server
|
||||
- `vite-plugin-wasm` - WebAssembly support for Vite
|
||||
- `typescript` - TypeScript compiler and language support
|
||||
|
||||
## Testing Integration
|
||||
|
||||
This example functions as an end-to-end test by:
|
||||
|
||||
1. **Import Validation**: Verifies `@llamaindex/cloud` can be imported in browser context
|
||||
2. **Instantiation Testing**: Tests that `LlamaParseReader` can be created without errors
|
||||
3. **Bundle Compatibility**: Ensures the build process handles all dependencies correctly
|
||||
4. **Runtime Verification**: Validates the application loads and runs in actual browsers
|
||||
|
||||
## Browser Compatibility
|
||||
|
||||
The application targets modern browsers with:
|
||||
|
||||
- ES2020 language features
|
||||
- ES Modules support
|
||||
- WebAssembly support (for potential WASM dependencies)
|
||||
- Modern DOM APIs
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Minimal Implementation**: Keeps the example simple to focus on integration testing
|
||||
- **Cloud Service Focus**: Specifically tests browser compatibility with LlamaCloud services
|
||||
- **Build Validation**: Ensures the build process works end-to-end without browser-specific issues
|
||||
- **WASM Preparation**: Configured for WASM dependencies even if not currently used
|
||||
- **Type Safety**: Full TypeScript integration with proper DOM type definitions
|
||||
|
||||
## Common Issues
|
||||
|
||||
- **WASM Loading**: The `vite-plugin-wasm` handles WebAssembly module loading complexities
|
||||
- **SSR Exclusions**: Tiktoken is excluded from SSR to prevent Node.js-specific dependencies in browser builds
|
||||
- **Module Resolution**: Uses bundler module resolution for optimal compatibility with modern web tooling
|
||||
|
||||
This example serves as a foundation for integrating LlamaIndexTS cloud services into web applications and validates that the core cloud functionality works correctly in browser environments.
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "@llamaindex/llama-parse-browser-test",
|
||||
"private": true,
|
||||
"version": "0.0.68",
|
||||
"version": "0.0.58",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
@@ -10,8 +10,8 @@
|
||||
},
|
||||
"devDependencies": {
|
||||
"typescript": "^5.7.3",
|
||||
"vite": "^6.3.3",
|
||||
"vite-plugin-wasm": "^3.4.1"
|
||||
"vite": "^5.4.16",
|
||||
"vite-plugin-wasm": "^3.3.0"
|
||||
},
|
||||
"dependencies": {
|
||||
"@llamaindex/cloud": "workspace:*"
|
||||
|
||||
@@ -1,77 +1,5 @@
|
||||
# @llamaindex/next-agent-test
|
||||
|
||||
## 0.1.166
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
|
||||
## 0.1.165
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.4
|
||||
|
||||
## 0.1.164
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.1.163
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.2
|
||||
|
||||
## 0.1.162
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.1.161
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
|
||||
## 0.1.160
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.6
|
||||
|
||||
## 0.1.159
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.5
|
||||
|
||||
## 0.1.158
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.1.157
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
|
||||
## 0.1.156
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.1.155
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,121 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the Next.js Agent example in the LlamaIndexTS e2e testing suite.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/next-agent-test` package is a Next.js application example that demonstrates integration between LlamaIndexTS and Next.js, specifically showcasing agent functionality with React Server Components and streaming UI using the Vercel AI SDK.
|
||||
|
||||
This example serves as both an integration test for Next.js compatibility and a reference implementation for building LlamaIndex-powered chat applications with Next.js.
|
||||
|
||||
## Development Commands
|
||||
|
||||
Local development commands:
|
||||
|
||||
- `npm run dev` - Start the Next.js development server on http://localhost:3000
|
||||
- `npm run build` - Build the application for production
|
||||
- `npm run start` - Start the production server
|
||||
|
||||
From the workspace root:
|
||||
|
||||
- `pnpm build` - Build all packages (required before running this example)
|
||||
- `pnpm e2e` - Run e2e tests including this Next.js integration
|
||||
|
||||
## Architecture
|
||||
|
||||
### Next.js Configuration
|
||||
|
||||
The application uses a custom Next.js configuration with the LlamaIndex Next.js plugin:
|
||||
|
||||
- `next.config.mjs` imports and applies `withLlamaIndex` from `llamaindex/next`
|
||||
- Enables Edge Runtime compatibility for LlamaIndex components
|
||||
- Uses Next.js 15 with React 19
|
||||
|
||||
### Runtime Environment
|
||||
|
||||
- **Edge Runtime**: The main page (`src/app/page.tsx`) exports `runtime = "edge"` for Vercel Edge Runtime compatibility
|
||||
- **React Server Components**: Uses Next.js App Router with RSC architecture
|
||||
- **Streaming UI**: Integrates Vercel AI SDK's `createStreamableUI` for real-time agent responses
|
||||
|
||||
### Key Components
|
||||
|
||||
**Main Application (`src/app/page.tsx`):**
|
||||
|
||||
- Client component using React's `useFormState` hook
|
||||
- Triggers server action `chatWithAgent` with a simple form interface
|
||||
- Displays streaming agent responses in real-time
|
||||
|
||||
**Server Actions (`src/actions/index.tsx`):**
|
||||
|
||||
- `chatWithAgent` function creates an OpenAI agent and handles streaming chat
|
||||
- Uses `OpenAIAgent` from `@llamaindex/openai` package
|
||||
- Implements streaming response with `createStreamableUI` from AI SDK
|
||||
- Accepts question string and previous chat messages as parameters
|
||||
|
||||
**Test Page (`src/app/test/page.tsx`):**
|
||||
|
||||
- Simple import test that ensures `llamaindex` package loads correctly
|
||||
- Serves as a basic smoke test for package compatibility
|
||||
|
||||
### Dependencies
|
||||
|
||||
**Core Dependencies:**
|
||||
|
||||
- `llamaindex` - Main LlamaIndex package (workspace dependency)
|
||||
- `next` - Next.js framework (v15.3.0+)
|
||||
- `react` & `react-dom` - React 19 for latest features
|
||||
- `ai` - Vercel AI SDK for streaming UI components
|
||||
|
||||
**Development Dependencies:**
|
||||
|
||||
- TypeScript configuration for Next.js development
|
||||
- ESLint with Next.js specific rules
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Agent Integration
|
||||
|
||||
The example demonstrates how to:
|
||||
|
||||
1. Create an OpenAI agent with configurable tools
|
||||
2. Handle streaming chat responses in a server action
|
||||
3. Integrate with React's form state management
|
||||
4. Display real-time streaming responses in the UI
|
||||
|
||||
### Next.js Best Practices
|
||||
|
||||
- Uses App Router with proper server/client component separation
|
||||
- Implements React Server Actions for agent communication
|
||||
- Leverages Edge Runtime for optimal performance
|
||||
- Follows Next.js 15 conventions with React 19 features
|
||||
|
||||
## Testing Role
|
||||
|
||||
This example serves multiple testing purposes in the e2e suite:
|
||||
|
||||
1. **Next.js Compatibility**: Validates LlamaIndex works with latest Next.js versions
|
||||
2. **Edge Runtime Testing**: Ensures agent functionality works in edge environments
|
||||
3. **Streaming Integration**: Tests real-time agent responses with AI SDK
|
||||
4. **React Server Components**: Validates RSC compatibility with LlamaIndex agents
|
||||
5. **Build Integration**: Confirms Next.js build process works with LlamaIndex
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Build Dependency**: This example requires the LlamaIndex packages to be built first (`pnpm build` from workspace root)
|
||||
- **API Keys**: Real agent functionality requires OpenAI API key in environment variables
|
||||
- **Edge Runtime**: The application is configured for edge runtime compatibility, making it suitable for Vercel deployment
|
||||
- **Streaming UI**: Demonstrates modern streaming patterns for AI applications
|
||||
- **Framework Integration**: Shows best practices for integrating LlamaIndex with React-based frameworks
|
||||
|
||||
## Environment Requirements
|
||||
|
||||
- Node.js environment with Next.js support
|
||||
- OpenAI API key for real agent functionality (optional for basic testing)
|
||||
- Compatible with Vercel Edge Runtime and standard Node.js runtime
|
||||
|
||||
## Common Workflows
|
||||
|
||||
1. **Local Development**: Run `npm run dev` after building workspace packages
|
||||
2. **Testing Agent Flow**: Use the simple form interface to test streaming agent responses
|
||||
3. **Build Validation**: Run `npm run build` to ensure production build compatibility
|
||||
4. **Integration Testing**: Part of e2e test suite validating Next.js + LlamaIndex integration
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@llamaindex/next-agent-test",
|
||||
"version": "0.1.166",
|
||||
"version": "0.1.155",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"dev": "next dev",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
"use server";
|
||||
import { OpenAIAgent } from "@llamaindex/openai";
|
||||
import { createStreamableUI } from "ai/rsc";
|
||||
import type { ChatMessage } from "llamaindex";
|
||||
import { OpenAIAgent } from "llamaindex";
|
||||
|
||||
export async function chatWithAgent(
|
||||
question: string,
|
||||
|
||||
@@ -1,77 +1,5 @@
|
||||
# test-edge-runtime
|
||||
|
||||
## 0.1.165
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
|
||||
## 0.1.164
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.4
|
||||
|
||||
## 0.1.163
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.1.162
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.2
|
||||
|
||||
## 0.1.161
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.1.160
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
|
||||
## 0.1.159
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.6
|
||||
|
||||
## 0.1.158
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.5
|
||||
|
||||
## 0.1.157
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.1.156
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
|
||||
## 0.1.155
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.1.154
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,128 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaIndexTS Next.js Edge Runtime example.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/nextjs-edge-runtime-test` package is an end-to-end test example that validates LlamaIndexTS compatibility with Next.js Edge Runtime. This example serves as both a test case and a reference implementation for using LlamaIndex in Vercel Edge Runtime environments.
|
||||
|
||||
## Purpose
|
||||
|
||||
This example specifically tests:
|
||||
|
||||
- LlamaIndex package import compatibility in Edge Runtime
|
||||
- Next.js Edge Runtime environment detection
|
||||
- Proper runtime configuration for LlamaIndex in serverless edge environments
|
||||
- Integration with Next.js 15.x App Router using edge runtime
|
||||
|
||||
## Development Commands
|
||||
|
||||
Standard Next.js commands:
|
||||
|
||||
- `npm run dev` - Start development server
|
||||
- `npm run build` - Build for production
|
||||
- `npm start` - Start production server
|
||||
|
||||
From the workspace root:
|
||||
|
||||
- `pnpm build` - Build all packages (required before testing)
|
||||
- `pnpm e2e` - Run all e2e tests including this example
|
||||
|
||||
## Architecture
|
||||
|
||||
### Next.js Configuration
|
||||
|
||||
**next.config.mjs:**
|
||||
|
||||
- Uses `withLlamaIndex` wrapper from `llamaindex/next` for proper Edge Runtime configuration
|
||||
- Applies necessary bundling and polyfill configurations for LlamaIndex compatibility
|
||||
|
||||
### Runtime Configuration
|
||||
|
||||
**Edge Runtime Setup:**
|
||||
|
||||
- Both `src/app/layout.tsx` and `src/app/page.tsx` export `runtime = "edge"`
|
||||
- Forces Next.js to use Edge Runtime instead of Node.js runtime
|
||||
- Validates LlamaIndex works in constrained serverless environments
|
||||
|
||||
### Runtime Validation
|
||||
|
||||
**src/utils/llm.ts:**
|
||||
|
||||
- Imports the main `llamaindex` package to test compatibility
|
||||
- Performs runtime environment validation by checking for `EdgeRuntime` global
|
||||
- Throws error if not running in expected Edge Runtime environment
|
||||
- Acts as a smoke test for package loading in edge environments
|
||||
|
||||
### Application Structure
|
||||
|
||||
**App Router Setup:**
|
||||
|
||||
- Uses Next.js 13+ App Router with TypeScript
|
||||
- Minimal React components for testing runtime compatibility
|
||||
- CSS imports to validate bundling works correctly
|
||||
- Path aliases configured for `@/*` imports
|
||||
|
||||
## Key Features
|
||||
|
||||
### Edge Runtime Compatibility
|
||||
|
||||
- Tests LlamaIndex package loading in Vercel Edge Runtime
|
||||
- Validates proper tree-shaking and bundling for edge environments
|
||||
- Ensures no Node.js-specific APIs are accidentally imported
|
||||
|
||||
### LlamaIndex Integration
|
||||
|
||||
- Uses workspace dependency `llamaindex: "workspace:*"`
|
||||
- Leverages `withLlamaIndex` Next.js plugin for proper configuration
|
||||
- Tests base package import without specific providers
|
||||
|
||||
### Environment Detection
|
||||
|
||||
- Runtime environment validation ensures code runs in expected context
|
||||
- Prevents deployment issues by catching runtime mismatches early
|
||||
- Provides clear error messages for debugging
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Core Dependencies:**
|
||||
|
||||
- `llamaindex` - Main LlamaIndexTS package (workspace dependency)
|
||||
- `next` - Next.js framework (v15.3.0)
|
||||
- `react` & `react-dom` - React framework (v19.x)
|
||||
|
||||
**Development Dependencies:**
|
||||
|
||||
- TypeScript types for Node.js, React, and React DOM
|
||||
- TypeScript compiler for type checking
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Build Dependency**: Ensure `pnpm build` is run from workspace root before testing
|
||||
- **Edge Runtime Only**: This example is specifically designed for Edge Runtime, not Node.js runtime
|
||||
- **Minimal Implementation**: Intentionally minimal to isolate Edge Runtime compatibility testing
|
||||
- **Import Testing**: The `src/utils/llm.ts` file serves as an import compatibility test
|
||||
- **Bundle Size**: Edge Runtime has size constraints, so this tests LlamaIndex bundle compatibility
|
||||
|
||||
## Testing Purpose
|
||||
|
||||
This example validates that:
|
||||
|
||||
1. LlamaIndex packages can be imported in Edge Runtime environments
|
||||
2. Next.js configuration works correctly with LlamaIndex
|
||||
3. Runtime environment detection functions properly
|
||||
4. Bundle size and tree-shaking work for edge deployments
|
||||
5. No Node.js-specific APIs are inadvertently used
|
||||
|
||||
## Common Issues
|
||||
|
||||
- **Runtime Detection Failures**: If `EdgeRuntime` is not detected, check Next.js configuration
|
||||
- **Import Errors**: Ensure workspace packages are built before running
|
||||
- **Bundle Size**: Edge Runtime has memory/size limits that may affect large imports
|
||||
- **API Compatibility**: Some LlamaIndex features may not work in Edge Runtime due to API limitations
|
||||
|
||||
## Related Examples
|
||||
|
||||
- `../nextjs-node-runtime/` - Node.js runtime equivalent
|
||||
- `../cloudflare-worker-agent/` - Cloudflare Workers edge runtime
|
||||
- `../nextjs-agent/` - Full Next.js agent implementation
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@llamaindex/nextjs-edge-runtime-test",
|
||||
"version": "0.1.165",
|
||||
"version": "0.1.154",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"dev": "next dev",
|
||||
|
||||
@@ -1,100 +1,5 @@
|
||||
# @llamaindex/next-node-runtime
|
||||
|
||||
## 0.1.33
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
- @llamaindex/huggingface@0.1.13
|
||||
- @llamaindex/readers@3.1.7
|
||||
|
||||
## 0.1.32
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/huggingface@0.1.12
|
||||
- llamaindex@0.11.4
|
||||
- @llamaindex/readers@3.1.6
|
||||
|
||||
## 0.1.31
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.1.30
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- @llamaindex/huggingface@0.1.11
|
||||
- llamaindex@0.11.2
|
||||
- @llamaindex/readers@3.1.5
|
||||
|
||||
## 0.1.29
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.1.28
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
- @llamaindex/huggingface@0.1.10
|
||||
- @llamaindex/readers@3.1.4
|
||||
|
||||
## 0.1.27
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [76c9a80]
|
||||
- @llamaindex/huggingface@0.1.9
|
||||
- llamaindex@0.10.6
|
||||
- @llamaindex/readers@3.1.3
|
||||
|
||||
## 0.1.26
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.5
|
||||
- @llamaindex/huggingface@0.1.8
|
||||
- @llamaindex/readers@3.1.2
|
||||
|
||||
## 0.1.25
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.1.24
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
- @llamaindex/huggingface@0.1.7
|
||||
- @llamaindex/readers@3.1.1
|
||||
|
||||
## 0.1.23
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [1e59695]
|
||||
- @llamaindex/readers@3.1.0
|
||||
|
||||
## 0.1.22
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
- @llamaindex/huggingface@0.1.6
|
||||
|
||||
## 0.1.21
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,129 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the Next.js Node Runtime example package.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/next-node-runtime-test` package is an end-to-end test example that demonstrates LlamaIndexTS integration with Next.js running on the Node.js runtime. This example validates that LlamaIndex packages work correctly in a Next.js App Router environment with server-side rendering and server actions.
|
||||
|
||||
## Development Commands
|
||||
|
||||
From this directory:
|
||||
|
||||
- `npm run dev` - Start development server on http://localhost:3000
|
||||
- `npm run build` - Build the Next.js application
|
||||
- `npm run start` - Start production server
|
||||
|
||||
From the e2e root directory:
|
||||
|
||||
- `pnpm e2e` - Run all e2e tests including this example
|
||||
|
||||
## Application Structure
|
||||
|
||||
### Configuration Files
|
||||
|
||||
- `next.config.mjs` - Next.js configuration with LlamaIndex integration using `withLlamaIndex()`
|
||||
- `tsconfig.json` - TypeScript configuration for Next.js with App Router
|
||||
- `package.json` - Dependencies including `llamaindex`, `@llamaindex/huggingface`, and `@llamaindex/readers`
|
||||
|
||||
### Source Structure
|
||||
|
||||
**App Router Pages:**
|
||||
|
||||
- `src/app/page.tsx` - Home page that demonstrates tokenizer usage with `runtime = "nodejs"`
|
||||
- `src/app/layout.tsx` - Root layout component with Inter font
|
||||
|
||||
**API Routes:**
|
||||
|
||||
- `src/app/api/openai/route.ts` - POST endpoint that calls OpenAI server action
|
||||
|
||||
**Server Actions:**
|
||||
|
||||
- `src/actions/openai.ts` - Server action demonstrating full LlamaIndex workflow with OpenAI agent
|
||||
|
||||
**Utilities:**
|
||||
|
||||
- `src/utils/tokenizer.ts` - Runtime validation and tokenization example
|
||||
|
||||
## Key Features Demonstrated
|
||||
|
||||
### 1. Runtime Validation (`src/utils/tokenizer.ts`)
|
||||
|
||||
Tests that the application runs in Node.js runtime (not Edge):
|
||||
|
||||
```typescript
|
||||
// @ts-expect-error EdgeRuntime is not defined in type
|
||||
if (typeof EdgeRuntime === "string") {
|
||||
throw new Error("Expected to not run in EdgeRuntime");
|
||||
}
|
||||
```
|
||||
|
||||
Uses LlamaIndex tokenizers:
|
||||
|
||||
```typescript
|
||||
import { Tokenizers, tokenizers } from "@llamaindex/env/tokenizers";
|
||||
```
|
||||
|
||||
### 2. OpenAI Agent Integration (`src/actions/openai.ts`)
|
||||
|
||||
Demonstrates a complete LlamaIndex workflow:
|
||||
|
||||
- **LLM Configuration**: OpenAI GPT-4o with API key management
|
||||
- **Embedding Model**: HuggingFace BAAI/bge-small-en-v1.5 embeddings
|
||||
- **Document Loading**: SimpleDirectoryReader for local file processing
|
||||
- **Vector Index**: VectorStoreIndex creation from documents
|
||||
- **Tool Integration**: Query engine as a tool for the agent
|
||||
- **Agent Creation**: OpenAIAgent with tools for conversational AI
|
||||
- **Callback Handling**: Event listeners for tool calls and results
|
||||
|
||||
### 3. Next.js Integration
|
||||
|
||||
- **Server Actions**: "use server" directive for server-side LlamaIndex operations
|
||||
- **API Routes**: RESTful endpoint for external integration
|
||||
- **App Router**: Modern Next.js routing with TypeScript support
|
||||
- **LlamaIndex Plugin**: `withLlamaIndex()` wrapper for proper bundling
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Core LlamaIndex:**
|
||||
|
||||
- `llamaindex` - Main LlamaIndex package
|
||||
- `@llamaindex/huggingface` - HuggingFace embedding models
|
||||
- `@llamaindex/readers` - Document readers including SimpleDirectoryReader
|
||||
|
||||
**Next.js Stack:**
|
||||
|
||||
- `next@^15.3.0` - Next.js framework
|
||||
- `react@19.0.0` & `react-dom@19.0.0` - React runtime
|
||||
- `typescript@^5.7.3` - TypeScript support
|
||||
|
||||
## Testing Purpose
|
||||
|
||||
This example serves as an integration test for:
|
||||
|
||||
1. **Node.js Runtime Compatibility**: Ensures LlamaIndex works in Next.js Node.js runtime
|
||||
2. **Server Actions**: Validates server-side LlamaIndex operations
|
||||
3. **Document Processing**: Tests file reading and vector indexing
|
||||
4. **Agent Workflows**: Validates OpenAI agent with tool integration
|
||||
5. **Bundling**: Ensures proper webpack bundling with `withLlamaIndex()`
|
||||
6. **API Integration**: Tests REST API endpoints with LlamaIndex backend
|
||||
|
||||
## Environment Variables
|
||||
|
||||
- `NEXT_PUBLIC_OPENAI_KEY` - OpenAI API key (falls back to "FAKE_KEY_TO_PASS_TESTS" for testing)
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Runtime Enforcement**: Explicitly sets `runtime = "nodejs"` in page components
|
||||
- **Error Handling**: Comprehensive try-catch in server actions
|
||||
- **Callback Management**: Event listeners for debugging tool interactions
|
||||
- **Testing Compatibility**: Fake API key fallback for automated testing
|
||||
- **Bundle Optimization**: Uses `withLlamaIndex()` for proper webpack configuration
|
||||
- **Type Safety**: Full TypeScript support with Next.js type definitions
|
||||
|
||||
## Common Workflows
|
||||
|
||||
1. **Local Development**: `npm run dev` to start development server with hot reload
|
||||
2. **Production Testing**: `npm run build && npm run start` to test production build
|
||||
3. **Integration Testing**: Run from e2e root with `pnpm e2e` for automated validation
|
||||
4. **Agent Testing**: POST to `/api/openai` endpoint with query payload for agent responses
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@llamaindex/next-node-runtime-test",
|
||||
"version": "0.1.33",
|
||||
"version": "0.1.21",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"dev": "next dev",
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
"use server";
|
||||
import { HuggingFaceEmbedding } from "@llamaindex/huggingface";
|
||||
import { OpenAI, OpenAIAgent } from "@llamaindex/openai";
|
||||
import { SimpleDirectoryReader } from "@llamaindex/readers/directory";
|
||||
import { Settings, VectorStoreIndex } from "llamaindex";
|
||||
import { OpenAI, OpenAIAgent, Settings, VectorStoreIndex } from "llamaindex";
|
||||
|
||||
Settings.llm = new OpenAI({
|
||||
apiKey: process.env.NEXT_PUBLIC_OPENAI_KEY ?? "FAKE_KEY_TO_PASS_TESTS",
|
||||
|
||||
@@ -1,77 +1,5 @@
|
||||
# vite-import-llamaindex
|
||||
|
||||
## 0.0.32
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
|
||||
## 0.0.31
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.4
|
||||
|
||||
## 0.0.30
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.0.29
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.2
|
||||
|
||||
## 0.0.28
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.0.27
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
|
||||
## 0.0.26
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.6
|
||||
|
||||
## 0.0.25
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.5
|
||||
|
||||
## 0.0.24
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.0.23
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
|
||||
## 0.0.22
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.0.21
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,108 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the vite-import-llamaindex example package.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `vite-import-llamaindex` package is a minimal Vite-based compatibility test that validates LlamaIndexTS can be properly imported and bundled in browser environments using Vite. This example serves as both an integration test and a demonstration of bundle size validation.
|
||||
|
||||
## Purpose
|
||||
|
||||
This example specifically tests:
|
||||
|
||||
- **Vite Bundler Compatibility**: Ensures LlamaIndexTS works correctly with Vite's bundling system
|
||||
- **Browser Import Validation**: Validates that the `llamaindex` package can be imported in browser-compatible builds
|
||||
- **Bundle Size Monitoring**: Uses size-limit to track and validate bundle output size
|
||||
- **Dual Module Support**: Tests both ESM and CJS output formats through Vite's library mode
|
||||
|
||||
## Development Commands
|
||||
|
||||
Local package commands:
|
||||
|
||||
- `npm run build` - Build the example using Vite library mode
|
||||
- `npm run size-limit` - Check bundle size against configured limits
|
||||
|
||||
From the root directory:
|
||||
|
||||
- `pnpm build` - Build all packages (required before testing)
|
||||
- `pnpm e2e` - Run all e2e tests including this example
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
vite-import-llamaindex/
|
||||
├── src/
|
||||
│ └── main.ts # Main entry point that imports llamaindex
|
||||
├── public/
|
||||
│ └── vite.svg # Vite logo asset
|
||||
├── package.json # Package configuration with size-limit setup
|
||||
├── vite.config.ts # Vite library build configuration
|
||||
├── tsconfig.json # TypeScript configuration
|
||||
└── CHANGELOG.md # Version history
|
||||
```
|
||||
|
||||
## Configuration Details
|
||||
|
||||
### Vite Configuration (`vite.config.ts`)
|
||||
|
||||
- **Library Mode**: Configured to build as a library with dual format output (ESM + CJS)
|
||||
- **Entry Point**: `src/main.ts` as the main entry
|
||||
- **Output Name**: `LlamaIndexImportTest`
|
||||
- **Formats**: Both ES modules and CommonJS for compatibility testing
|
||||
|
||||
### TypeScript Configuration (`tsconfig.json`)
|
||||
|
||||
- **Target**: ES2020 for modern browser compatibility
|
||||
- **Module System**: ESNext with bundler resolution for Vite
|
||||
- **Strict Mode**: Enabled with comprehensive linting rules
|
||||
- **DOM Types**: Includes DOM and DOM.Iterable for browser environment
|
||||
|
||||
### Bundle Size Monitoring
|
||||
|
||||
The package uses `size-limit` to monitor bundle size:
|
||||
|
||||
```json
|
||||
"size-limit": [
|
||||
{
|
||||
"path": "dist/LlamaIndexImportTest.js"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
This ensures the bundled output remains within reasonable size constraints for browser applications.
|
||||
|
||||
## Test Approach
|
||||
|
||||
The test validates:
|
||||
|
||||
1. **Import Success**: The `llamaindex` package can be imported without errors
|
||||
2. **Bundle Generation**: Vite can successfully bundle the code into browser-compatible output
|
||||
3. **Size Validation**: The resulting bundle meets size requirements
|
||||
4. **Module Compatibility**: Both ESM and CJS outputs are generated correctly
|
||||
|
||||
## Dependencies
|
||||
|
||||
- **`llamaindex`**: Workspace dependency for testing the main package
|
||||
- **`vite`**: Build tool and bundler
|
||||
- **`typescript`**: TypeScript compiler
|
||||
- **`@size-limit/preset-big-lib`**: Bundle size analysis for libraries
|
||||
- **`size-limit`**: Bundle size monitoring tool
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **Build Dependency**: This example depends on the main `llamaindex` package being built first
|
||||
- **Browser Focus**: Specifically tests browser compatibility, not Node.js environments
|
||||
- **Size Monitoring**: Bundle size is actively monitored to prevent bloat
|
||||
- **Minimal Example**: Kept intentionally simple to isolate bundling issues
|
||||
- **Integration Test**: Serves as both an example and an automated test in the e2e suite
|
||||
|
||||
## Common Issues
|
||||
|
||||
1. **Build Failures**: Ensure `pnpm build` is run from the root before testing this example
|
||||
2. **Size Limit Violations**: If bundle size exceeds limits, investigate dependency bloat
|
||||
3. **Import Errors**: Check that the `llamaindex` package exports are browser-compatible
|
||||
4. **TypeScript Errors**: Verify TypeScript configuration matches Vite requirements
|
||||
|
||||
## Relationship to E2E Testing
|
||||
|
||||
This example is part of the broader e2e testing suite and validates that LlamaIndexTS maintains browser compatibility. It ensures that when users integrate LlamaIndexTS with Vite in their own projects, they won't encounter bundling or import issues.
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "vite-import-llamaindex",
|
||||
"private": true,
|
||||
"version": "0.0.32",
|
||||
"version": "0.0.21",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"build": "vite build",
|
||||
@@ -16,7 +16,7 @@
|
||||
"@size-limit/preset-big-lib": "^11.1.6",
|
||||
"size-limit": "^11.1.6",
|
||||
"typescript": "^5.7.3",
|
||||
"vite": "^6.3.3"
|
||||
"vite": "^5.4.16"
|
||||
},
|
||||
"dependencies": {
|
||||
"llamaindex": "workspace:*"
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
{"root":["./src/main.ts","./vite.config.ts"],"version":"5.7.3"}
|
||||
@@ -1,79 +1,5 @@
|
||||
# @llamaindex/waku-query-engine-test
|
||||
|
||||
## 0.0.166
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.5
|
||||
|
||||
## 0.0.165
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.4
|
||||
|
||||
## 0.0.164
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.3
|
||||
|
||||
## 0.0.163
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.2
|
||||
|
||||
## 0.0.162
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.11.1
|
||||
|
||||
## 0.0.161
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [b0cd530]
|
||||
- Updated dependencies [361a685]
|
||||
- llamaindex@0.11.0
|
||||
|
||||
## 0.0.160
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.6
|
||||
|
||||
## 0.0.159
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [9b2e25a]
|
||||
- @llamaindex/env@0.1.30
|
||||
- llamaindex@0.10.5
|
||||
|
||||
## 0.0.158
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [2225ffd]
|
||||
- Updated dependencies [6ddf1c1]
|
||||
- Updated dependencies [41953a3]
|
||||
- llamaindex@0.10.4
|
||||
|
||||
## 0.0.157
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- Updated dependencies [3ee8c83]
|
||||
- llamaindex@0.10.3
|
||||
|
||||
## 0.0.156
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- llamaindex@0.10.2
|
||||
|
||||
## 0.0.155
|
||||
|
||||
### Patch Changes
|
||||
|
||||
@@ -1,131 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with the LlamaIndexTS Waku Query Engine example.
|
||||
|
||||
## Package Overview
|
||||
|
||||
The `@llamaindex/waku-query-engine-test` package demonstrates LlamaIndexTS integration with the Waku React framework. This example showcases how to build a document query interface using LlamaIndex's VectorStoreIndex and QueryEngine capabilities within a Waku application that supports both static rendering and server actions.
|
||||
|
||||
## Development Commands
|
||||
|
||||
- `npm run dev` - Start Waku development server
|
||||
- `npm run build` - Build the application for production
|
||||
- `npm run start` - Start the production server
|
||||
|
||||
## Architecture
|
||||
|
||||
### Framework Integration
|
||||
|
||||
This example uses **Waku 0.22.2**, a lightweight React framework that supports:
|
||||
|
||||
- React Server Components (RSC)
|
||||
- Server actions with "use server" directive
|
||||
- Static site generation with `render: "static"` config
|
||||
- Client-side hydration with "use client" components
|
||||
|
||||
### LlamaIndex Integration
|
||||
|
||||
The core LlamaIndex functionality is implemented in `src/actions.ts`:
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- **Document Loading**: Reads text from `node_modules/llamaindex/examples/abramov.txt`
|
||||
- **Vector Index**: Creates embeddings using `VectorStoreIndex.fromDocuments()`
|
||||
- **Query Engine**: Provides semantic search capabilities via `index.asQueryEngine()`
|
||||
- **Lazy Loading**: QueryEngine is initialized once and cached for subsequent requests
|
||||
|
||||
**Data Flow:**
|
||||
|
||||
1. User inputs question in chat interface (`src/components/chat.tsx`)
|
||||
2. Form submission triggers server action (`chatWithAI`)
|
||||
3. Server action queries the VectorStoreIndex
|
||||
4. Response is returned and displayed in the UI
|
||||
|
||||
### Component Structure
|
||||
|
||||
**Server Components:**
|
||||
|
||||
- `src/pages/_layout.tsx` - Root layout with static metadata
|
||||
- `src/pages/index.tsx` - Home page with static rendering config
|
||||
- `src/components/header.tsx` - Navigation header
|
||||
- `src/components/footer.tsx` - Site footer
|
||||
|
||||
**Client Components:**
|
||||
|
||||
- `src/components/chat.tsx` - Interactive chat interface with form state management
|
||||
|
||||
### Styling
|
||||
|
||||
- **TailwindCSS 4.1.4** for utility-first styling
|
||||
- **PostCSS** for CSS processing
|
||||
- **Nunito font** via Google Fonts
|
||||
- Responsive design with mobile-first approach
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Core Dependencies:**
|
||||
|
||||
- `@llamaindex/env` - Runtime environment compatibility
|
||||
- `llamaindex` - Main LlamaIndexTS package for document indexing and querying
|
||||
- `waku` - React framework for SSR/SSG
|
||||
- `react` & `react-dom` - React 19.0.0 with experimental features
|
||||
- `react-server-dom-webpack` - React Server Components support
|
||||
|
||||
**Development Dependencies:**
|
||||
|
||||
- `typescript` - TypeScript 5.7.3 with strict mode
|
||||
- `tailwindcss` & `@tailwindcss/postcss` - Styling framework
|
||||
- `rollup` - Build tool used by Waku
|
||||
|
||||
## TypeScript Configuration
|
||||
|
||||
- **Target**: ESNext with modern features
|
||||
- **Module**: ESNext with bundler resolution
|
||||
- **React**: Experimental types for React 19 features
|
||||
- **Strict**: Full TypeScript strict mode enabled
|
||||
|
||||
## Key Features Demonstrated
|
||||
|
||||
1. **Server Actions Integration**: Seamless LlamaIndex queries via Waku server actions
|
||||
2. **Document RAG**: Retrieval-Augmented Generation using vector embeddings
|
||||
3. **Static Generation**: Pages are statically rendered while maintaining interactive features
|
||||
4. **React 19 Features**: Uses latest React with experimental types
|
||||
5. **Modern Styling**: TailwindCSS 4.x with PostCSS integration
|
||||
|
||||
## Testing Context
|
||||
|
||||
This example serves as an end-to-end test for:
|
||||
|
||||
- LlamaIndexTS compatibility with Waku framework
|
||||
- React Server Components integration
|
||||
- Vector store and query engine functionality
|
||||
- Server action patterns with LlamaIndex
|
||||
- Build and deployment workflows
|
||||
|
||||
## Development Notes
|
||||
|
||||
- **File Loading**: Uses `@llamaindex/env` fs abstraction for cross-platform file access
|
||||
- **Query Caching**: QueryEngine is lazily loaded and cached for performance
|
||||
- **Error Handling**: Basic error handling in server actions and form submissions
|
||||
- **Bundle Size**: Waku's optimized bundling ensures minimal client-side JavaScript
|
||||
- **Runtime Support**: Compatible with Node.js runtime environments
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**Adding New Documents:**
|
||||
|
||||
1. Place document files in accessible location
|
||||
2. Update `lazyLoadQueryEngine()` to load additional documents
|
||||
3. Rebuild vector index with new document set
|
||||
|
||||
**Extending Chat Interface:**
|
||||
|
||||
1. Modify `Chat` component for enhanced UI features
|
||||
2. Update `chatWithAI` server action for additional processing
|
||||
3. Add error states and loading indicators as needed
|
||||
|
||||
**Styling Updates:**
|
||||
|
||||
1. Modify TailwindCSS classes in components
|
||||
2. Update `tailwind.config.js` for custom configurations
|
||||
3. Use `src/styles.css` for global styles
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user