If you have shipped more than a few Node.js applications, you already know the quiet tax you pay at the start of every project.
You do not start with your product. You start with decisions: which router, which ORM, which auth library, which queue, which mail transport, which validation layer, which folder structure, which CLI. Then you spend days making those pieces agree with each other — and months keeping their versions aligned.
I built ArikaJS because I wanted that tax to go away.
ArikaJS is an open-source, TypeScript-first web framework for Node.js. It is inspired by the developer experience of Laravel, but designed for the Node ecosystem: modular packages, a real CLI, and one coherent way to build APIs and full-stack apps.
This post is the story of why it exists, what it includes today, and how you can try it — honestly, as of v0.10.x on npm, while I continue building toward v1.0.
The problem I kept running into
Node.js is excellent at being flexible. That flexibility is also the problem.
In PHP, Laravel (and similar frameworks) give you a default path: auth, Eloquent, migrations, queues, mail, artisan commands, config files that feel like one product. You can disagree with parts of it, but you rarely start from zero.
In Node, the default path is often a blank package.json and a pile of blog posts.
You might pick Express or Fastify for HTTP. Prisma or Knex or TypeORM for data. Passport or a custom JWT stack for auth. Bull for queues. Nodemailer for email. Zod for validation. Then you invent your own conventions for controllers, service providers, env loading, and deployment.
None of those libraries are bad. Many are excellent. The pain is integration:
- Different APIs and mental models
- Different release cycles
- Documentation that never describes your whole stack
- Onboarding a teammate means explaining five tools instead of one framework
I wanted something closer to a single solution: install once, scaffold once, and ship features — not glue code.
What I wanted ArikaJS to feel like
A few non-negotiables guided the design:
- TypeScript first — types and DX as a default, not an afterthought.
- Laravel-inspired ergonomics — familiar concepts (CLI, migrations, guards, providers) without copying PHP blindly.
- Modular packages —
@arikajs/auth,@arikajs/database,@arikajs/router, and friends should be clear and independently publishable. - One umbrella — the
arikajspackage should wire them together so users do not manage twenty version pins by hand. - A real CLI —
arika new, migrations, generators, auth installers, queue workers — because frameworks earn trust through tools, not only README diagrams. - Atomic versioning — when foundation changes, the rest of the ecosystem should move together (pnpm workspaces, Turborepo, Changesets).
The goal is simple to say and hard to execute:
A developer should not need to be a DevOps expert to use ArikaJS. They should just be a product builder.
What ArikaJS is today
ArikaJS is a monorepo of 30+ packages published under the @arikajs/* scope, plus the main arikajs framework package and @arikajs/cli.
At a high level:
| Area | What you get |
|---|---|
| Foundation | Application lifecycle, DI container, service providers, config |
| HTTP | Request/response, router, dispatcher, middleware, session |
| Data | Eloquent-style ORM, migrations, MySQL / PostgreSQL / SQLite |
| Security | Multi-guard auth (session, JWT, token, basic), authorization, encryption |
| Services | Cache, queue, scheduler, mail, events, storage, validation, views, i18n |
| DX | arika CLI — scaffolding, make:*, migrate, queue work, auth install |
| Ops | Docs site, Discord, and arika-deploy for PM2 + Nginx + SSL style workflows |
You create an app with:
npx @arikajs/cli new my-app
cd my-app
npm run dev
From there, familiar commands help you move fast:
arika migrate
arika make:model Post --migration
arika auth:install:api
# or
arika auth:install:web
Web auth scaffolds session-based flows and views. API auth scaffolds JWT-oriented routes. Same ecosystem — different guards for different surfaces.
Architecture in one paragraph
Under the hood, ArikaJS follows a layered model:
Your application sits on top of arikajs, which re-exports and registers subsystem providers. @arikajs/foundation owns the container and boot lifecycle. The HTTP layer (router → dispatcher → middleware) handles requests. Feature packages (auth, database, cache, queue, mail, …) plug in through service providers and drivers.
That structure is intentional. It lets the framework stay broad without becoming one unmaintainable mega-file — and it lets me improve one package without pretending the others do not exist.
Honest status: published, not “finished”
ArikaJS is on npm today (arikajs and @arikajs/cli around v0.10.x). People can scaffold apps and explore the stack.
I am not calling it a finished v1.0 product yet.
I am actively working toward v1.0 with a clear north star: FlowBoard, a real reference application (boards, lists, tasks) that is meant to stress-test auth, ORM relationships, queues, mail, cache, and views together. If FlowBoard can be built cleanly on ArikaJS, the framework is ready for a stable major release. If it exposes friction, I fix the framework first.
That honesty matters. Open source earns trust when creators tell you what works and what is still being sharpened.
Who ArikaJS is for
ArikaJS is a good fit if you:
- Like Laravel’s “batteries included” feel but work primarily in Node/TypeScript
- Want APIs and server-rendered views in one ecosystem
- Prefer a CLI-driven workflow over assembling a micro-stack every time
- Care about modular packages with coordinated releases
It may not be the right choice yet if you need only a minimal HTTP router, or if you require every Eloquent edge-case and battle-tested production war stories tomorrow. The roadmap is public for a reason — I am building in the open.
How you can help (and try it)
If this resonates:
- Try the scaffold —
npx @arikajs/cli new my-app - Read the docs — arikajs.github.io
- Star / watch the repo — github.com/ArikaJs/arikajs
- Install from npm — npmjs.com/package/arikajs
- Join the conversation — Discord linked from the docs and README
Feedback from Node and TypeScript developers is especially valuable right now: what would make you try a new framework, and what would make you stay?
Closing
ArikaJS started as a personal answer to a recurring professional frustration: Node apps deserve a coherent framework experience, not only a marketplace of parts.
It is open source (MIT), TypeScript-native, modular, and already publishable. It is also still climbing toward v1.0 — with intention, tests, a real reference app, and a community I hope grows with the code.
If you build APIs or full-stack apps on Node, I would love for you to try ArikaJS and tell me what you want next.
Links
- GitHub: https://github.com/ArikaJs/arikajs
- npm: https://www.npmjs.com/package/arikajs
- Docs: https://arikajs.github.io/
- CLI:
npx @arikajs/cli new my-app