What Is the Purpose of the `src` Directory in usekaneo/kaneo?

The src directories in usekaneo/kaneo contain all typed TypeScript source files—the functional code for the API server, React frontend, and shared packages that power the entire platform.

Every src folder in this monorepo serves as the dedicated home for implementation logic. These directories are deliberately separated from configuration files, tests, and build artifacts, letting developers focus solely on core features. Whether you're adding API endpoints, building UI components, or sharing utilities across apps, the src directory is where all meaningful development happens.

What the src Directory Contains Across the Monorepo

Kaneo uses a Turborepo-based monorepo structure with multiple src directories, each serving a distinct purpose:

Package/App	src Path	Purpose
API (apps/api)	apps/api/src	Hono-based backend server, routes, database schema, authentication, WebSocket handling
Web (apps/web)	apps/web/src	React frontend components, hooks, query fetchers, utilities
Shared Libraries (packages/*)	packages/*/src	Reusable code: API client, email templates, permissions, MCP (Kaneo Control Panel)

This separation ensures clean architectural boundaries while enabling type-safe imports between packages.

Backend: apps/api/src — The Hono Server Implementation

The API's src directory implements the entire backend infrastructure. In apps/api/src/index.ts, the Hono application is instantiated and all feature routes are wired together:

// From apps/api/src/index.ts
const app = new Hono();

// Feature routes mounted here
api.route("/project", project);
api.route("/task", task);
api.route("/workspace", workspace);

This entry point also configures middleware stacks including CORS, authentication verification, and WebSocket adapters. Every business-logic controller, database interaction, and route handler lives under this src tree.

Frontend: apps/web/src — React Components and Client Logic

The web application's src directory contains the complete React implementation. This includes page components, custom hooks for data fetching, utility libraries, and TypeScript type definitions.

Consider apps/web/src/lib/utils/create-slug.ts, a small but representative utility:

export function createSlug(name: string): string {
  return name
    .toLowerCase()
    .trim()
    .replace(/[^\w\s-]/g, "")
    .replace(/[\s_-]+/g, "-")
    .replace(/^-+|-+$/g, "");
}

This function normalizes strings into URL-friendly slugs—the kind of reusable client-side logic that populates apps/web/src.

Shared Packages: Cross-Cutting src Code

The packages/*/src directories contain infrastructure code imported by multiple apps. A critical example is packages/libs/src/hono.ts, which builds a type-safe Hono client for API consumption:

export const client = hc<AppType>(apiUrl, {
  fetch: (input, init) =>
    fetch(input, {
      ...init,
      headers: {
        ...init?.headers,
        "Content-Type": "application/json",
        "X-Kaneo-Window-Id": windowId,
      },
      credentials: "include",
    })
});

This client automatically injects the X-Kaneo-Window-Id header for request tracing across the system, demonstrating how src folders in packages enable centralized, maintainable logic.

Build Pipeline: From src to Production

The src directories are compilation sources, not runtime artifacts. The build pipeline transforms them as follows:

• Web app: Vite compiles apps/web/src into optimized browser bundles
• API: The src files are executed directly via TypeScript or transpiled for deployment
• Packages: Biome handles linting and type-checking before distribution

This compile-step separation means src stays free of generated files, keeping version control clean and developer navigation straightforward.

Key Files Illustrating src Directory Purpose

File	Location	Role
index.ts	apps/api/src/	Backend bootstrap and route mounting
create-slug.ts	apps/web/src/lib/utils/	Frontend utility function
hono.ts	packages/libs/src/	Typed API client for cross-app use
index.ts	packages/permissions/src/	Permission logic shared system-wide

Each file exemplifies the centralized implementation pattern that makes src directories the definitive location for functional code.

Summary

• src directories contain all typed TypeScript implementation—no configuration, no tests, no build artifacts
• apps/api/src powers the Hono backend with routes, middleware, and business logic
• apps/web/src delivers the React frontend through components, hooks, and utilities
• packages/*/src shares cross-cutting libraries like typed API clients and permission systems
• Build tools (Vite, Biome) compile src into production bundles, keeping source and output cleanly separated

Frequently Asked Questions

Why does usekaneo/kaneo use multiple src directories instead of one?

Kaneo follows monorepo best practices where each application and package maintains its own src directory. This enforces strict architectural boundaries: the API cannot accidentally import frontend code, and shared packages explicitly declare their public interfaces. The structure scales cleanly as the project grows.

What build tools process the src files in Kaneo?

Vite handles the web app's src compilation and bundling. Biome provides linting and formatting across all TypeScript src files. The API's src runs under TypeScript execution or transpilation depending on deployment context.

Can I add new features by only editing files in src directories?

Yes. The src directories are designed as the sole location for functional code changes. New API endpoints go in apps/api/src/routes/. New UI components belong in apps/web/src/components/. Shared utilities belong in the appropriate packages/*/src/ folder. Configuration files, test files, and build outputs live elsewhere by design.

How does packages/libs/src/hono.ts differ from direct fetch calls?

The Hono client in packages/libs/src/hono.ts provides end-to-end type safety: TypeScript knows exactly what request shapes each API route accepts and what responses it returns. It also centralizes cross-cutting concerns like the X-Kaneo-Window-Id header and credential handling, eliminating duplicate boilerplate across the web app.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}