Package reference

@damatjs/framework

Damatjs framework for handling everything

• @damatjs/framework — Internals

  @damatjs/framework — Internals Maintainer notes for the core framework. This index gives the module map, the end-to-end boot/request flow, and the global invariants; the split docs cover each concern in depth. Module map File / dir | Respon

• Bootstrap

  Bootstrap Source: , driven by , types in . Responsibility assembles a ready-to-serve Hono from config, route directory, and (optional) health checks. It is the step between "services are initialized" and "start the server". It does not star

• Config

  Config Source: — , , . Responsibility Define and load the application configuration ( ). is an identity helper that gives you type-checking and inference; dynamically imports the config file at runtime and caches it. Pure identity — its onl

• Handlers (built-in routes)

  Handlers (built-in routes) Source: — , , , . Responsibility A small set of framework-provided routes mounted by (separate from the file-based application routes). Each factory returns a fresh sub-app that gets -mounted. Factory | Mounted wh

• Middleware

  Middleware Source: — , , , , , , , . Responsibility Two kinds of middleware: - Global — installed once on the app by (security headers, timing, request setup, CORS, error wrapper). - Per-route — factories the router attaches to specific met

• Router (file-based routing)

  Router (file-based routing) Source: — , , , , , . Responsibility Turn a directory of files into a mounted Hono router. The router maps folder structure to URL paths, attaches per-route middleware, rate limiting, auth, and validation, and ex

• Server & shutdown

  Server & shutdown Source: , , and . Server starts the Hono app through , passing and optional . It returns a : is idempotent. It waits for a server that is still starting, closes the listener, and shares one promise across repeated calls. T

• Services (wiring)

  Services (wiring) Source: — , shared service adapters, and stages for database, Redis, modules, auth, durability, wakeups, jobs, and durable events. Responsibility brings up the shared application layer before optional HTTP: logger, Postgre

@damatjs/services

Damatjs services definition

• @damatjs/services — Internals

  @damatjs/services — Internals Maintainer notes for the service layer. Three concerns: the factory that generates CRUD classes, the static that holds the shared pool, and that produces lazy, typed module instances. Module map File / dir | Re

• `defineModule` & module instances

  & module instances Source: , . Responsibility packages a service class plus a credentials loader into a — the object a Damat app default-exports from its module folder and that discovers and registers. The instance's is a that constructs th

• `ModuleService` & generated CRUD

  & generated CRUD Source: , , , , , , , , , . Responsibility is a class factory . Given a map of model name → (and an optional zod credentials schema), it returns an abstract base class that: - validates credentials in its constructor, - reg

• `PoolManager`

  Source: . Responsibility is the single, process-wide holder of the PostgreSQL connection pool, the built on top of it, and (optionally) a . Generated services and read the entity manager from here; they never construct their own. It is a cl

@damatjs/module

Damatjs module system — manifest contract, standalone dev/test harness, and registry tooling for self-contained modules

• @damatjs/module internals

  @damatjs/module internals Maintainer map for module contracts, standalone execution, tooling, artifact resolution, and registry trust. Public usage starts in the package README; the manifest contract is MODULES.md. Responsibilities Concern

• Authoring ownership

  Authoring ownership owns the portable module contract and standalone module runtime. General application authoring APIs stay with the packages that implement them. Import map Concern | Import from | ----------------------------- | ---------

• Module config (`module.config.ts`)

  Module config ( ) Source: , , . is the only thing a module author has to configure for the standalone runtime. Everything else — server, database wiring, migrations, tests — is provided by the module runtime with sane defaults. The file is

• Harness — standalone dev & test

  Harness — standalone dev & test Source: , , , , . The harness boots a single module without an HTTP server — it wires the same infrastructure the framework uses in production ( + ), applies the declared module migration path and required lo

• Manifest internals

  Manifest internals The public contract is MODULES.md. This page maps that contract to implementation ownership. Universal envelope parses the strict universal fields: Unknown top-level, install, capability, and module keys are rejected. Man

• Registry — refs, resolution, trust

  Registry — refs, resolution, trust Source: , , , , , , . The registry layer is how modules will be addressed, distributed, and trusted once the hosted registry exists. The backend that performs owner-identity and source verification is not

• Runtime — module as a live app

  Runtime — module as a live app Source: , , , , , , and . The runtime runs one module package as a capability-aware development host. It uses the framework HTTP stack, imports manifest-declared provider barrels, and starts local PostgreSQL-b

• Tooling — migrations & codegen

  Tooling — migrations & codegen Source: , . Helpers that operate on a standalone module package — no required. They locate the module dir, read its manifest, and drive the ORM migration and module-generator owners directly. The CLI calls the

@damatjs/module-generator

Damat module discovery, code generation, scaffolding, and barrels

• @damatjs/module-generator internals

  @damatjs/module-generator internals owns the Damat-specific, filesystem-writing half of code generation. Pure schema rendering remains in . Source map Directory | Responsibility | --------------- | ------------------------------------------

@damatjs/link

Cross-module links for Damat — define relationships between two modules, generate the junction table, migrate it, and query linked records across modules.

• @damatjs/link — internals

  @damatjs/link — internals This package implements cross-module links. It deliberately reuses the existing ORM and service machinery: a junction table is just an ordinary , and the link module is just a instance, so migrations, snapshots, an

@damatjs/workflow-engine

Damatjs saga-style workflow engine built on Effect-TS

• @damatjs/workflow-engine — Internals

  @damatjs/workflow-engine — Internals Maintainer-facing documentation for the workflow engine. For the public overview and quick start, see the package README. What this package is A saga-style, in-process workflow orchestrator built on Effe

• Control flow helpers

  Control flow helpers Source: , , , . These are thin, composable wrappers that return Effects so they slot into a workflow generator alongside . They add no engine behavior of their own beyond what does (except , which adds concurrency). A r

• Errors

  Errors Source: , , , . All errors extend . Every error carries a programmatic and a (Effect-style discriminant). The workflow result's field is always a (or subclass). (base) It is also used directly with two codes produced by the workflow

• Distributed locking

  Distributed locking Source: , . Backed by . The lock layer prevents two workflow executions that share a from running at the same time — across processes/instances, since the lock lives in Redis. It is a thin wrapper over 's lock primitives

• Retry & timeout

  Retry & timeout Source: , , , and the retry logic in . The attempts model counts retries , not total tries. With , a step that always fails runs 3 times (1 initial + 2 retries) and then fails with . This is asserted in ("exhausted retries f

• Steps

  Steps Source: , , , . A step is the unit of work. It is a typed function ( ) plus an optional (undo) function and per-step config. is what actually runs it inside a workflow, applying retry, timeout, and registering compensation. returns a

• Workflows

  Workflows Source: , , , , , . A workflow composes steps. returns a definition with two run methods: (plain) and (mutually-exclusive via Redis). The is your orchestration: an Effect generator that s calls. Its error channel is and it require

@damatjs/orm

Damat ORM

• @damatjs/orm — Internals

  @damatjs/orm — Internals Maintainer-facing notes for the ORM umbrella package. This package is deliberately tiny: it is a re-export aggregator with no behaviour of its own. - architecture.md — the re-export model, subpath wiring, and how to

• Architecture — @damatjs/orm

  Architecture — @damatjs/orm is an umbrella / meta-package . It exists to give consumers a single dependency and a stable import name for the whole Damat ORM, while the actual implementation stays split across focused packages. The re-export

@damatjs/orm-model

Damatjs orm model definition

• @damatjs/orm-model — Internals

  @damatjs/orm-model — Internals Maintainer documentation for the schema-definition DSL. This package is the largest in the ORM stack and the one most likely to change as new column types, relation features, and validation rules are added. Re

• Column builders

  Column builders Covers (the base), every concrete column type, the factory object, and . All live under , , and . The factory ( ) is a plain object whose methods are the public DSL surface. Each column method returns a fresh builder instanc

• Indexes and constraints

  Indexes and constraints Covers , , and the index-normalisation helper. Source under , , and . Both builders are reached either via the factory ( , ) or via the dedicated factory functions ( , ), and are attached to a model with / . ( ) : 1.

• Relations

  Relations Covers the three relation builders, the abstract base, target resolution, and the relation validators. Source under and . Mental model A relation has two sides: - Owning side — . Lives on the table that holds the foreign key. It i

• Schema and model definition

  Schema and model definition Covers and the factory, , , the global model registry, and the timestamps/soft-delete behavior. Source: , , , . and ( ) ( ) is the allowed property union: . holds builder-phase state: Self-registration The constr

• Type inference helpers

  Type inference helpers Covers how PostgreSQL types map to TypeScript inside the model DSL, how enum/row types are emitted, and the string-case helpers. Source: , , the methods, and . ( ) maps a to the base TypeScript type string (without nu

@damatjs/orm-pg

PostgreSQL ORM core for @damatjs - EntityManager, Repository pattern, and query execution

• @damatjs/orm-pg — Internals

  @damatjs/orm-pg — Internals Maintainer-facing documentation for the PostgreSQL execution layer. For the consumer-facing overview see the package README. This index maps the source tree, explains the layered architecture and data flow, recor

• Model Client

  Model Client Sources: , , . is the per-model CRUD layer. It glues the pure query layer ( ) to the executor ( / ). Unlike it returns the full result shape — — so callers also get the JSON of each query. - is — the pure SQL/JSON factory. - is

• Entity Manager

  Entity Manager Sources: , , . The manager layer is the top-level entry point. It wraps a , owns a , caches one per model, and runs transactions. is also re-exported as from the package root. On construction it: 1. stores , 2. builds a logge

• Executor

  Executor Sources: , . The executor is the thin seam between the pure query layer and the driver. It is the only place in the package that calls for builder-generated SQL, and the single point where query logging happens. Everything above it

• Query Builder

  Query Builder Sources: , , , , , , , , . This is the pure layer: it turns a plus an options object into a ( ) and a JSON . Nothing here touches a database connection. WHERE-clause compilation is split out into where.md; relation ( ) loading

• Relations (`with` eager loading)

  Relations ( eager loading) Sources: , , , and the relation paths in . eager-loads related rows by compiling each relation into a subquery that returns the related data as JSON. Relations are resolved from the model's relation builders ( / /

• Repository

  Repository Sources: , . is the ergonomic CRUD surface. Where returns , the repository unwraps those into plain rows / single rows / counts, and adds convenience methods ( , , , , …). One repository wraps one model. — the factory Connection

• Transactions

  Transactions Sources: , , . This is the dedicated transaction layer used by . It is distinct from the client-level transaction ( → , see executor.md): Path | Driver | Savepoints? | Isolation options? | ----------------------------- | ------

• WHERE compilation

  WHERE compilation Sources: , . Relation-scoped WHERE compilation ( ) lives in and is covered in relations.md. This is where object-style conditions become parameterised SQL. Two kinds of clause exist: object clauses ( ) and raw clauses ( ).

@damatjs/orm-connector

Damatjs pg connection manager

• @damatjs/orm-connector — Internals

  @damatjs/orm-connector — Internals Maintainer-facing documentation for the PostgreSQL connection/pool manager. For the consumer-facing overview see the package README. Purpose This package has exactly one job: turn a into a live, observable

• Connection lifecycle — `ConnectionManager`

  Connection lifecycle — Source: . This document covers the stateful core of the package. Responsibility owns a single and its full lifecycle: lazy creation, idempotent connection, verification, health checks, client/stat access, and teardown

• Pool tools — listeners, status, errors & config presets

  Pool tools — listeners, status, errors & config presets The directory holds the stateless helpers that delegates to, plus the connection-error type and the pool-config presets. Each is independently unit-tested. — - is fixed to so callers c

@damatjs/orm-migration

Damatjs orm utils definition

• orm-migration internals

  orm-migration internals Maintainer-facing documentation for . For the public overview and quick start, see the package README. This package coordinates module-owned SQL files and ordered inline system migrations. Both use one advisory lock

• Discovery

  Discovery Source: Responsibility Find what exists on disk and in code: the migration files a module declares, and the model definitions a module exports. Discovery is read-only and (for files) does no database work — it produces records tha

• Executor

  Executor Source: Responsibility Apply pending migrations against a live database and report status. The executor is the only part of the package that runs SQL. It takes a (created and owned by the caller), ensures the tracker table and DB p

• Generator

  Generator Source: · Templating: Responsibility Create new migration files for a module from its current models. The generator is offline — it never touches the database. It discovers models, builds the current via , then uses to either emit

• Tracker

  Tracker Source: Responsibility Own the table — the single source of truth for which migrations have been applied (or reverted) for each module. The class is the only code that reads or writes this table; the executor and status layers go th

@damatjs/orm-processor

Damatjs orm processor definition

• orm-processor internals

  orm-processor internals Maintainer-facing documentation for . For the public overview and quick start, see the package README. The processor is a pure, stateless schema engine . Given the serialized shape (from ), it answers three questions

• Diff engine

  Diff engine Source: · Types: Responsibility Compare two s ( from the snapshot, built from models) and produce a : a flat, priority-sorted list of records plus non-fatal . The diff is the abstract, dialect-independent description of "what ch

• Snapshot layer

  Snapshot layer Source: Responsibility Persist and reload a module's schema as a single JSON file, , inside the module's migrations directory. This is the only part of the processor that touches the filesystem. Everything else operates on in

• SQL generator

  SQL generator Source: · Options/result types: Responsibility Turn abstract records (or a whole ) into PostgreSQL DDL strings. This layer is dialect-specific (PostgreSQL) and never reorders changes — it trusts the priority ordering establish

@damatjs/schema-codegen

Pure TypeScript and Zod source generation from Damat module schemas

• @damatjs/schema-codegen internals

  @damatjs/schema-codegen internals is a pure source renderer. Its only runtime dependency is . Source map Directory | Responsibility | ------------------- | ------------------------------------------------------------- | | PostgreSQL column

• Generators

  Generators Sources: , , Responsibility Compose the per-column primitives ( , ) plus enums and relations into whole TypeScript files. There are two output strategies: - Combined — everything for a module in one string ( , ). - File-per-table

• Type mapping

  Type mapping Sources: , Responsibility Convert a single into either a TypeScript type string or a Zod schema string. These are the leaf primitives every generator builds on. They are deliberately split into a base mapper (one type, no nulla

@damatjs/orm-core

Damat ORM core - database-agnostic registry, logging, and types

• @damatjs/orm-core — Internals

  @damatjs/orm-core — Internals Maintainer notes for the database-agnostic runtime layer. This package is small (four source files) but it is on the hot path of every driver: the registry is consulted on every name→table resolution and the lo

• QueryLogger (`src/logger.ts`)

  QueryLogger ( ) A structured logger that drivers call to record query activity in a uniform way. It wraps an and adds query-specific categories, each independently switchable. A process-wide singleton lets every driver share one configurati

• ModelRegistry (`src/registry.ts`)

  ModelRegistry ( ) A runtime index over s. Drivers build one, fill it with the app's models, and consult it during query construction to map logical names and table names to model metadata, and to resolve relation targets. ( ) Each entry cac

@damatjs/orm-type

Damat ORM shared types

• @damatjs/orm-type — Internals

  @damatjs/orm-type — Internals Maintainer-facing notes for the shared type package. This is a types-only package: every file under compiles to a and an empty/near-empty . There is no runtime behavior to reason about — the work here is keepin

• Connection and query types (`src/connection/`, `src/query/`)

  Connection and query types ( , ) Two type groups that have nothing to do with schema definition and everything to do with talking to the database: how a connection/pool is described, and how a query is represented as JSON before it is compi

• Schema snapshot types (`src/model/`)

  Schema snapshot types ( ) These types describe the serialized, JSON-able form of a Damat schema. They are produced by the fluent builders in and consumed by the registry ( ), the migration/DDL engine, and . Editing anything here ripples thr

@damatjs/logger

Damat logger

• @damatjs/logger — Internals

  @damatjs/logger — Internals Maintainer-facing documentation for . For the user-facing overview see the package README. It is a centralized, zero-dependency logging package: colorized console output plus an optional dual-format file transpor

• Child & prefixed loggers (and the no-op logger)

  Child & prefixed loggers (and the no-op logger) How context- and prefix-scoped loggers work. Covers ( ), the / factories on ( ), and ( ). All three classes implement the contract from . Responsibility Let callers create lightweight, scoped

• Formatting — levels, colors, and output formats

  Formatting — levels, colors, and output formats How turns a log call into a string. Covers the level system ( ), the ( ), and the ( ). These three files are internal — not re-exported from . Responsibility - Decide whether an entry passes t

• Global logger singleton & helpers

  Global logger singleton & helpers The process-global logger and the convenience functions that wrap it. Source: . All of these are re-exported from . Responsibility Provide one shared per process so application code (and library code that d

• File transport

  File transport ( ) is the optional, buffered, dual-format file sink. It is re-exported from , but is normally driven indirectly through (which constructs one from ). Responsibility Persist log entries to disk for post-mortem analysis withou

@damatjs/redis

Damatjs redis

• @damatjs/redis — Internals

  @damatjs/redis — Internals Maintainer-facing documentation. For usage see the package README. This package is a thin, function-first layer over ioredis. It is organized as one folder per concern; each folder is a barrel ( ) re-exporting a h

• Cache

  Cache Covers ( , , , , , , , ). Responsibility Key/value caching with TTL. Two flavors: JSON (serialize/parse objects) and raw (store strings verbatim), plus a tagged layer ( ) that indexes entries under tags so a whole group can be invalid

• Client lifecycle, factory, errors & types

  Client lifecycle, factory, errors & types Covers , , , , and . Responsibility Own the connection to Redis and hand a (ioredis) instance to everything else. There are two acquisition models — a process-global singleton and a standalone facto

• Counters

  Counters Covers ( , , , , ). Responsibility Atomic integer counters using Redis / . Unlike the other modules, counters use no key prefix — the caller fully controls the key (so you can namespace however you like, e.g. ). API Behavior - — wi

• Distributed locks

  Distributed locks Covers ( , , , , , ). Responsibility A single-holder distributed mutex. Acquisition is atomic ( ); release and extension are guarded by a Lua script that checks ownership, so a process can only release/extend a lock it sti

• Job queue — `RedisQueue`

  Job queue — Covers ( , , , ). Responsibility A Redis-backed priority + delay job queue. It provides storage and state-transition primitives (enqueue, dequeue a batch, update status, query, cancel, stats, clear) plus an optional visibility t

• Rate limiting

  Rate limiting Covers ( , , , ) and the rate-limit types in . Responsibility Sliding-window rate limiting backed by a Redis sorted set per identifier, with a multi-window wrapper (e.g. "60/min and 1000/hour"). Keys are prefixed with . Types

• Sessions

  Sessions Covers ( , , , , , ). Responsibility Token → JSON-data storage with TTL, plus a class that adds sliding expiration (auto-extend on read). All keys use . Function API - — . TTL is required (unlike cache). Overwrites any existing ses

@damatjs/events

Typed ephemeral subscriptions and transactional PostgreSQL durable events for Damat apps

• @damatjs/events — Internals

  @damatjs/events — Internals Maintainer-facing documentation. For usage see the package README. This package has two intentionally separate paths: an in-process with optional Redis fan-out, and PostgreSQL-backed durable event publishing. Eph

@damatjs/jobs

Durable PostgreSQL background jobs and fenced workers for Damat apps

• @damatjs/jobs — Internals

  @damatjs/jobs — Internals Maintainer notes for the PostgreSQL job runtime. See the package README for the public usage surface. Module map Area | Responsibility | ---------------- | -------------------------------------------------------- |

@damatjs/load-env

Damatjs load env

• @damatjs/load-env — Internals

  @damatjs/load-env — Internals Maintainer-facing documentation for . For the user-facing overview see the package README. This is a two-file package: a loader that decides which file to read and how to merge it into , and a parser that turns

• Architecture — load order & parsing

  Architecture — load order & parsing Deep dive into the two functions that make up . Source: (loader) and (parser). — load order & merge The candidate list For the cascade, in load order, is: 1. 2. 3. 4. Files are searched in only (no upward

@damatjs/types

Damat Types definition

• @damatjs/types — Internals

  @damatjs/types — Internals Maintainer-facing documentation for . For the user-facing overview see the package README. The package is intentionally tiny: a single source file declaring an error hierarchy plus one legacy helper. There is no b

• Error classes — the `AppError` hierarchy

  Error classes — the hierarchy All error types live in . This document covers the base class, each subclass, status-code mapping, serialization, and how to extend the set safely. Responsibility Provide a single, HTTP-aware error base ( ) and

@damatjs/cli

Framework-neutral embeddable TypeScript command runtime

• @damatjs/cli internals

  @damatjs/cli internals is a framework-neutral command runtime over . A call to receives or creates a , builds an invocation-owned registry and optional project-config state, parses the supplied arguments, runs one shared execution pipeline,

• Command and runtime model

  Command and runtime model All public types are exported from . preserves the concrete capability type. returns commands in capability and command order. Use from to run one capability with captured output and logs. describes the executable;

• Help and banner

  Help and banner Help and banner functions receive . They never write to global console state directly. Help Default help includes usage, optional description and commands, help/version options, and the hint. The verbose option appears only

• Output, diagnostics, and validation

  Output, diagnostics, and validation Output helpers Presentation helpers receive structural interfaces: Spacing and detail text use ; leveled messages use . returns a string and performs no output. Error reporting The explicit form is: The r

• Command registry

  Command registry returns a new . There is no module-level registry and no production reset operation. Registration rules - A command is stored under its . - Each alias points to the same command object. - A child command is stored under . -

• Run loop, parsing, context, and config

  Run loop, parsing, context, and config The run loop validates the CLI definition, creates runtime defaults, constructs an isolated registry, configures CAC, applies presentation policy, dispatches one command, and returns its result. It cre

@damatjs/deps

Dependencies for damatjs

• @damatjs/deps — Internals

  @damatjs/deps — Internals Maintainer notes for the dependency re-export package. It is intentionally tiny: each file is a re-export, and the value is concentrated in the (pinned versions + the map). Module map File | Responsibility | ------

• Architecture — @damatjs/deps

  Architecture — @damatjs/deps A reference for exactly what each subpath re-exports and how the package is wired. The map The published contract is the field in . Each subpath maps to a built file: Subpath contents (root, ) Every library unde

@damatjs/typescript-config

• @damatjs/typescript-config — Internals

  @damatjs/typescript-config — Internals Maintainer notes for the shared TypeScript presets. This package contributes only static JSON; there is no runtime code, no , and no build step. Module map File | Responsibility | --------------------

• Architecture — @damatjs/typescript-config

  Architecture — @damatjs/typescript-config A field-by-field reference for the three presets. All paths are relative to the package root. The shared base every backend package extends. Full contents: / are written with so they apply to the ex

@damatjs/provider

ModuleService-based provider authoring and role binding contracts for Damat

No indexed package docs were found for this package.

@damatjs/provider-auth

Strict ModuleService-based authentication provider contract for Damat

No indexed package docs were found for this package.

@damatjs/provider-payment

Strict ModuleService-based payment provider contract for Damat

No indexed package docs were found for this package.

@damatjs/provider-subscription

Strict ModuleService-based subscription provider contract for Damat

No indexed package docs were found for this package.

@damatjs/damat-cli

Damat CLI - Development and build tool for Damat.js

• Damat CLI composer internals

  Damat CLI composer internals composes the app, codegen, module, kit, and auth capabilities. passes that ordered command list to . is the only Damat-specific runtime adapter: it reads process state, creates the logger, and writes output to t

@damatjs/cli-codegen

Damat application code generation CLI capability

• Codegen CLI internals

  Codegen CLI internals The package adapts to a Damat application. Eligibility, generation reporting, linked-field resolution, and file augmentation are independent units. Pure schema rendering is owned by and is consumed through the module g

@damatjs/orm-cli

Damatjs ORM CLI - database migration commands

• @damatjs/orm-cli — Internals

  @damatjs/orm-cli — Internals Maintainer-facing reference for the CLI. Read alongside the package README, which covers user-facing usage. Split docs - migrate-commands.md — , , , . - generate-commands.md — the unregistered source and the pub

• Config loading & path resolution

  Config loading & path resolution How turns a and a module id into concrete model, migration, and types directories. Sources: , , . — Loads the map from a config file and normalizes it. Steps: 1. Resolve : absolute is used as-is; otherwise .

• Generate commands

  Generate commands is migrations-only: registers only . Public type generation runs through in an app or in a module package. Those commands use , which owns discovery, output, registries, scaffolds, and barrels. The unregistered handler is

• Migrate commands

  Migrate commands lives beside the migrate group. It loads the same configured URL, connects to the target, and on PostgreSQL checks/creates that database through the standard database. It then calls , so database creation and all selected s

@damatjs/mcp

Model Context Protocol (MCP) server for discovering and installing Damat modules with AI

• @damatjs/mcp — internals

  @damatjs/mcp — internals Maintainer-facing notes for the Damat module MCP server. Audience: people changing the server. What this is A dependency-free MCP server that runs directly under Bun (no build step). Its code is split into small mod