Multiple source folders. Directory-based nested routing. Runtime end-to-end validation. Generated fetch clients, OpenAPI spec. Koa, Hono, SolidJS, React, Vue and more.
It's a meta-framework that gives your Vite project a scalable shape:
- Multiple source folders for distinct areas (website, admin dashboard, API).
- Each folder splits into
api/andpages/, creating a clean boundary between server and client. - Generators that produce validation schemas, fetch clients, and
OpenAPIspecs from your types.
KosmoJS is named after the Greek "Kosmos" (κόσμος), meaning "order" or "world",
reflecting the focus on organized, structured project architecture.
npm create kosmo
# or `pnpm create kosmo` / `yarn create kosmo`After the project is created, navigate to your app directory:
cd ./my-appAll subsequent operations run from inside this directory.
Use your favorite package manager:
npm install
# or `pnpm install` / `yarn install`npm run +folder
# or `pnpm +folder` / `yarn +folder`The source folder may have added new dependencies. Run the package manager again:
npm install
# or `pnpm install` / `yarn install`npm run dev
# or `pnpm dev` / `yarn dev`Each source folder runs on its own port with its own base URL.
-
🗂️ Multiple Source Folders
Organize distinct concerns - public site, customer app, admin dashboard - all connected in one Vite project. -
🛣️ Directory-Based Nested Routing
Your folder structure defines your routes. Works identically for both API endpoints and client pages -
🛡️ End-to-End Type Safety
WriteTypeScripttypes once, get runtime validation automatically. No separate schemas to maintain. -
🔗 Generated Fetch Clients + OpenAPI spec
Fully-typed fetch clients with client-side validation. Invalid requests never reach your server. -
🎨 Multiple Frameworks
Currently supportsKoa/Honofor backend,SolidJS/React/Vuefor frontend. Additional frameworks may be added based on community interest. -
🔧 Built on Proven Tools
No proprietary abstractions, just the tools you already know (or easy to learn).
- Monorepo-like projects where frontend and API must live side by side.
- Teams needing strong typing and runtime validation without duplicating schemas.
- Developers who want framework freedom while keeping consistent structure.
- Projects that must scale from prototype to production with a deterministic structure.
Contributions are welcome! Check out the issues and submit PRs. Please follow the project's coding style and include tests when possible.