CodexaCodexa

Providers

Every third-party package Codexa Core depends on, re-exported so a project never installs or maps them separately.

Codexa Core's own modules are built on a handful of well-established third-party packages. Rather than making a project install and configure each one itself, every dependency is re-exported through @codexa/core/providers, so importing from @codexa/core is enough.

import { MongoClient } from '@codexa/core/providers/mongodb';
import { zod } from '@codexa/core/providers/zod';
import Redis from '@codexa/core/providers/ioredis';

Two ways to import a provider

A dedicated subpath, @codexa/core/providers/<name>, gives the full package surface directly, exactly as if you had installed it yourself.

import { zod } from '@codexa/core/providers/zod';
import { createRouter } from '@codexa/core/providers/rou3';

The providers namespace subpath gives every provider as a named export instead, useful when you want several of them from one import line.

import { zod, mongodb, ioredis } from '@codexa/core/providers';

const client = new mongodb.MongoClient(uri);

Reach for the dedicated subpath in most code, it is what every example on this site uses. The namespace form mainly helps when writing a small script that touches several providers at once.

What is re-exported

SubpathPackageNotes
@codexa/core/providers/path@std/path
@codexa/core/providers/zod@zod/zodAlso exports zod as an alias for Zod's z namespace, and ZodInfer, ZodInput, ZodOutput, AnyZodObject type helpers
@codexa/core/providers/dotenv@std/dotenvBacks loadEnv's .env file loading
@codexa/core/providers/ioredisioredisThe client type behind createRedisConnection
@codexa/core/providers/mongodbmongodbIncludes ObjectId, see Database (MongoDB)
@codexa/core/providers/qsqsBacks parseQueryParams
@codexa/core/providers/rou3rou3The radix tree router the HTTP layer matches routes with internally
@codexa/core/providers/ua-parser-jsua-parser-jsBacks parseDevice
@codexa/core/providers/noble-hashes@noble/hashesBacks blake2bDigest, exported as several submodule namespaces since the package has no single root module

@codexa/core/zod also exists as a shorter compatibility alias for @codexa/core/providers/zod. New code should prefer the full providers/zod path.

Why this exists

Two problems this avoids: a version of mongodb in your deno.json drifting out of sync with the one Codexa Core itself was built and tested against, and having to separately install and pin every dependency Codexa Core already needs internally, just to get its types.

On this page