Skip to content

Commit 7e20c54

Browse files
zRelaxzzRelaxz
committed
🐛 fix(docs): resolve code indentation error due to a wrong push that reverted some files
1 parent 390e3e1 commit 7e20c54

232 files changed

Lines changed: 16338 additions & 7898 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎en/cli/cli-database.mdx‎

Lines changed: 82 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -5,11 +5,11 @@ description: |
55
Choose your ORM and database engine through the interactive wizard, then start writing queries immediately.
66
order: 5
77
category: CLI
8-
---
8+
---
99

1010
## What it does
1111

12-
`spraxium database` (alias `spraxium db`) generates a fully wired database module inside your project. It walks you through an interactive wizard where you select an ORM and a database engine, then scaffolds the module files, patches your environment config with the required keys, installs the necessary packages, and optionally registers the module in your *AppModule*. By the end of the wizard your project is ready to run queries with no manual configuration.
12+
`spraxium database` (alias `spraxium db`) generates a fully wired database module inside your project. It walks you through an interactive wizard where you select an ORM and a database engine, then scaffolds the module files, patches your environment config with the required keys, installs the necessary packages, and optionally registers the module in your _AppModule_. By the end of the wizard your project is ready to run queries with no manual configuration.
1313

1414
The command accepts an optional ORM argument to skip the first selection step. When you already know what you want, `spraxium database prisma` jumps directly to the database engine prompt.
1515

@@ -21,45 +21,89 @@ Use this command at the beginning of a project or when adding database access to
2121

2222
<DropdownGroup>
2323
<Dropdown title="Prisma, schema-first with auto-generated client">
24-
Prisma is the best choice when you want a strongly typed query client generated from a declarative schema file. It supports PostgreSQL, MySQL, and SQLite out of the box. After the wizard runs, define your models in `prisma/schema.prisma` and run `npx prisma migrate dev` to apply changes. Prisma is ideal for teams that prefer schema-as-source-of-truth workflows, readable migration history, and full TypeScript type safety from database to application layer.
24+
Prisma is the best choice when you want a strongly typed query client
25+
generated from a declarative schema file. It supports PostgreSQL, MySQL, and
26+
SQLite out of the box. After the wizard runs, define your models in
27+
`prisma/schema.prisma` and run `npx prisma migrate dev` to apply changes.
28+
Prisma is ideal for teams that prefer schema-as-source-of-truth workflows,
29+
readable migration history, and full TypeScript type safety from database to
30+
application layer.
2531
</Dropdown>
2632
<Dropdown title="Drizzle, lightweight SQL-native TypeScript ORM">
27-
Drizzle is suited for projects that value small bundle size, direct SQL control, and schema defined in TypeScript rather than a separate file. It supports PostgreSQL, MySQL, and SQLite. The generated *DatabaseService* exposes a `.getDb()` method that returns the Drizzle query builder, ready to use. Choose Drizzle when you want minimal abstraction with full TypeScript inference and prefer defining tables as TypeScript objects over `.prisma` syntax.
33+
Drizzle is suited for projects that value small bundle size, direct SQL
34+
control, and schema defined in TypeScript rather than a separate file. It
35+
supports PostgreSQL, MySQL, and SQLite. The generated *DatabaseService*
36+
exposes a `.getDb()` method that returns the Drizzle query builder, ready to
37+
use. Choose Drizzle when you want minimal abstraction with full TypeScript
38+
inference and prefer defining tables as TypeScript objects over `.prisma`
39+
syntax.
2840
</Dropdown>
2941
<Dropdown title="TypeORM, decorator-based with Active Record or Data Mapper">
30-
TypeORM is the established choice for teams coming from NestJS or Spring backgrounds who are comfortable with class decorators such as *@Entity*, *@Column*, and *@Repository*. It supports PostgreSQL, MySQL, and SQLite. Use TypeORM when your team prefers entity classes as the source of truth and wants a familiar pattern for migrations and relation management.
42+
TypeORM is the established choice for teams coming from NestJS or Spring
43+
backgrounds who are comfortable with class decorators such as *@Entity*,
44+
*@Column*, and *@Repository*. It supports PostgreSQL, MySQL, and SQLite. Use
45+
TypeORM when your team prefers entity classes as the source of truth and
46+
wants a familiar pattern for migrations and relation management.
3147
</Dropdown>
3248
<Dropdown title="Mongoose, document model for MongoDB">
33-
Mongoose is the right pick when your data is document-oriented and MongoDB is your database. It has a single database target, so the wizard skips the engine selection step. The generated module includes a schema definition and a service that wraps the Mongoose model. Choose Mongoose for applications that need flexible schemas, embedded documents, or MongoDB-specific query operators.
49+
Mongoose is the right pick when your data is document-oriented and MongoDB
50+
is your database. It has a single database target, so the wizard skips the
51+
engine selection step. The generated module includes a schema definition and
52+
a service that wraps the Mongoose model. Choose Mongoose for applications
53+
that need flexible schemas, embedded documents, or MongoDB-specific query
54+
operators.
3455
</Dropdown>
3556
<Dropdown title="Mikro-ORM, versatile ORM with Unit of Work pattern">
36-
Mikro-ORM is a strong choice for advanced use cases that benefit from the Unit of Work pattern and Identity Map. It supports PostgreSQL, MySQL, SQLite, and MongoDB. Mikro-ORM is well suited for complex domain models with deep relation graphs, where controlled change tracking across a request lifecycle matters more than simplicity of setup.
57+
Mikro-ORM is a strong choice for advanced use cases that benefit from the
58+
Unit of Work pattern and Identity Map. It supports PostgreSQL, MySQL,
59+
SQLite, and MongoDB. Mikro-ORM is well suited for complex domain models with
60+
deep relation graphs, where controlled change tracking across a request
61+
lifecycle matters more than simplicity of setup.
3762
</Dropdown>
3863
</DropdownGroup>
3964

4065
## What the wizard does
4166

4267
<Steps>
4368
<Step title="ORM selection">
44-
If you did not pass an ORM as a CLI argument, the wizard presents an interactive list of the five supported ORMs with a short description for each. Navigate with the arrow keys and press Enter to confirm.
69+
If you did not pass an ORM as a CLI argument, the wizard presents an
70+
interactive list of the five supported ORMs with a short description for
71+
each. Navigate with the arrow keys and press Enter to confirm.
4572
</Step>
4673
<Step title="Database engine selection">
47-
For ORMs that support multiple engines (Prisma, Drizzle, TypeORM, Mikro-ORM), the wizard asks which engine to target. Mongoose skips this step because it only targets MongoDB.
74+
For ORMs that support multiple engines (Prisma, Drizzle, TypeORM,
75+
Mikro-ORM), the wizard asks which engine to target. Mongoose skips this step
76+
because it only targets MongoDB.
4877
</Step>
4978
<Step title="Module name">
50-
The wizard prompts for a module name with `database` as the default. The name is converted to kebab-case for the folder and PascalCase for the class names. A name like `user-db` produces a `UserDbModule` and a `src/modules/user-db/` directory.
79+
The wizard prompts for a module name with `database` as the default. The
80+
name is converted to kebab-case for the folder and PascalCase for the class
81+
names. A name like `user-db` produces a `UserDbModule` and a
82+
`src/modules/user-db/` directory.
5183
</Step>
5284
<Step title="File scaffolding">
53-
The CLI downloads the template for your ORM and engine combination and writes the module, service, schema, and config files into `src/modules/{name}/`. A root-level config file (such as `drizzle.config.ts` or `prisma/schema.prisma`) is also added if the ORM requires it.
85+
The CLI downloads the template for your ORM and engine combination and
86+
writes the module, service, schema, and config files into `src/modules/
87+
{name}/`. A root-level config file (such as `drizzle.config.ts` or
88+
`prisma/schema.prisma`) is also added if the ORM requires it.
5489
</Step>
5590
<Step title="Environment key injection">
56-
The required environment variables (`DATABASE_URL`, `DATABASE_PATH`, etc.) are appended to your `app.env.ts` automatically if they are not already present. No manual editing needed.
91+
The required environment variables (`DATABASE_URL`, `DATABASE_PATH`, etc.)
92+
are appended to your `app.env.ts` automatically if they are not already
93+
present. No manual editing needed.
5794
</Step>
5895
<Step title="Package installation">
59-
The wizard asks if you want to install packages immediately. Confirming runs the detected package manager to add runtime dependencies (such as the ORM client and database driver) and dev dependencies (CLI tools, type definitions). Post-install commands like `npx prisma generate` are also run automatically.
96+
The wizard asks if you want to install packages immediately. Confirming runs
97+
the detected package manager to add runtime dependencies (such as the ORM
98+
client and database driver) and dev dependencies (CLI tools, type
99+
definitions). Post-install commands like `npx prisma generate` are also run
100+
automatically.
60101
</Step>
61102
<Step title="AppModule registration">
62-
If an `app.module.ts` is found in your `src/` directory, the wizard offers to add the generated module to the *imports* array automatically. This connects the module to the DI container so you can inject the *DatabaseService* anywhere in the application.
103+
If an `app.module.ts` is found in your `src/` directory, the wizard offers
104+
to add the generated module to the *imports* array automatically. This
105+
connects the module to the DI container so you can inject the
106+
*DatabaseService* anywhere in the application.
63107
</Step>
64108
</Steps>
65109

@@ -69,31 +113,47 @@ The exact files vary by ORM but the layout follows the same convention for every
69113

70114
<FolderStructure>
71115
<Folder name="src/modules/database/">
72-
<File name="database.module.ts" description="Module class with @Module decorator and provider exports" />
73-
<File name="database.service.ts" description="Injectable service exposing the ORM client or query builder" />
74-
<File name="database.schema.ts" description="Schema or entity definition (present for Drizzle, Mongoose, Mikro-ORM)" />
116+
<File
117+
name="database.module.ts"
118+
description="Module class with @Module decorator and provider exports"
119+
/>
120+
<File
121+
name="database.service.ts"
122+
description="Injectable service exposing the ORM client or query builder"
123+
/>
124+
<File
125+
name="database.schema.ts"
126+
description="Schema or entity definition (present for Drizzle, Mongoose, Mikro-ORM)"
127+
/>
75128
</Folder>
76129
</FolderStructure>
77130

78131
<Callout tone="info" title="Root-level config files are also created">
79-
Some ORMs require a configuration file at the project root. Prisma generates a prisma/ directory with schema.prisma. Drizzle generates drizzle.config.ts. These files are written alongside the module files and should be committed to version control.
132+
Some ORMs require a configuration file at the project root. Prisma generates a
133+
prisma/ directory with schema.prisma. Drizzle generates drizzle.config.ts.
134+
These files are written alongside the module files and should be committed to
135+
version control.
80136
</Callout>
81137

82138
## After the wizard
83139

84-
Once the command finishes, you can inject *DatabaseService* into any handler, guard, or service within the same module scope. The service is exported from the database module, so importing *DatabaseModule* in any other module gives you access to it through the DI container.
140+
Once the command finishes, you can inject _DatabaseService_ into any handler, guard, or service within the same module scope. The service is exported from the database module, so importing _DatabaseModule_ in any other module gives you access to it through the DI container.
85141

86142
```typescript filename="src/modules/hello/hello.service.ts"
87-
import { Injectable } from '@spraxium/common';
88-
import { DatabaseService } from '../database/database.service';
143+
import { Injectable } from "@spraxium/common";
144+
import { DatabaseService } from "../database/database.service";
89145

90146
@Injectable()
91147
export class HelloService {
92148
constructor(private readonly db: DatabaseService) {}
93149

94150
async getCount(): Promise<number> {
95151
// Use the ORM client returned by the service
96-
return this.db.getDb().select().from(table).then((rows) => rows.length);
152+
return this.db
153+
.getDb()
154+
.select()
155+
.from(table)
156+
.then((rows) => rows.length);
97157
}
98158
}
99159
```

‎en/cli/cli-dev.mdx‎

Lines changed: 32 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -9,11 +9,11 @@ category: CLI
99

1010
## Overview
1111

12-
Three commands cover the full development lifecycle in Spraxium: *spraxium dev* for local iteration, *spraxium build* for producing a production artifact, and *spraxium start* for running that artifact. This page covers all three so you never need to jump between pages to understand how they connect.
12+
Three commands cover the full development lifecycle in Spraxium: _spraxium dev_ for local iteration, _spraxium build_ for producing a production artifact, and _spraxium start_ for running that artifact. This page covers all three so you never need to jump between pages to understand how they connect.
1313

1414
## spraxium dev
1515

16-
*spraxium dev* starts a file-watching development server that restarts the application automatically when source files change. It uses SWC for loading TypeScript without a separate compile step, keeping restart times short even in large projects. The watcher fires based on the `include` and `exclude` glob patterns in your configuration, and applies a configurable debounce to batch rapid file saves into a single restart.
16+
_spraxium dev_ starts a file-watching development server that restarts the application automatically when source files change. It uses SWC for loading TypeScript without a separate compile step, keeping restart times short even in large projects. The watcher fires based on the `include` and `exclude` glob patterns in your configuration, and applies a configurable debounce to batch rapid file saves into a single restart.
1717

1818
```bash filename="terminal"
1919
spraxium dev
@@ -24,7 +24,12 @@ spraxium dev
2424
```typescript filename="spraxium.config.ts"
2525
export default {
2626
dev: {
27-
entrypoint: 'src/main.ts', include: ['src/**'], exclude: ['src/**/*.spec.ts'], debounce: 300, }, };
27+
entrypoint: "src/main.ts",
28+
include: ["src/**"],
29+
exclude: ["src/**/*.spec.ts"],
30+
debounce: 300,
31+
},
32+
};
2833
```
2934

3035
<DropdownGroup>
@@ -33,11 +38,14 @@ export default {
3338
</Dropdown>
3439

3540
<Dropdown title="include">
36-
Glob patterns for files that can trigger a restart. Narrowing this list reduces noisy restarts from files that should not affect runtime behavior.
41+
Glob patterns for files that can trigger a restart. Narrowing this list
42+
reduces noisy restarts from files that should not affect runtime behavior.
3743
</Dropdown>
3844

3945
<Dropdown title="exclude">
40-
Files matched here are ignored by the watcher even if they fall inside an `include` pattern. Use this to skip test files, generated code, or any path that changes frequently without affecting the running process.
46+
Files matched here are ignored by the watcher even if they fall inside an
47+
`include` pattern. Use this to skip test files, generated code, or any path
48+
that changes frequently without affecting the running process.
4149
</Dropdown>
4250

4351
<Dropdown title="debounce">
@@ -46,7 +54,8 @@ export default {
4654
</DropdownGroup>
4755

4856
<Callout tone="info" title="Default excludes are always on">
49-
Even with no config block, the watcher ignores node_modules, .git, and .spraxium to prevent restart loops from dependency installs or build output.
57+
Even with no config block, the watcher ignores node_modules, .git, and
58+
.spraxium to prevent restart loops from dependency installs or build output.
5059
</Callout>
5160

5261
### Crash recovery
@@ -57,7 +66,7 @@ If the bot process crashes, the dev server does not exit. It applies an exponent
5766

5867
## spraxium build
5968

60-
*spraxium build* validates types and produces a production-ready bundle. It runs in two sequential steps: first a type-check pass and then the bundler. If the type-check fails, the bundler never runs, so you get a clean exit code that CI pipelines can rely on.
69+
_spraxium build_ validates types and produces a production-ready bundle. It runs in two sequential steps: first a type-check pass and then the bundler. If the type-check fails, the bundler never runs, so you get a clean exit code that CI pipelines can rely on.
6170

6271
```bash filename="terminal"
6372
spraxium build
@@ -67,24 +76,31 @@ spraxium build
6776

6877
<Steps>
6978
<Step title="Type-check">
70-
Runs `tsc --noEmit` against your project. Any type error fails the command immediately. Fix all TypeScript errors before the bundler can proceed.
79+
Runs `tsc --noEmit` against your project. Any type error fails the command
80+
immediately. Fix all TypeScript errors before the bundler can proceed.
7181
</Step>
7282
<Step title="Bundle">
73-
Runs `tsdown` with your project's configuration. If a `tsdown.config.*` file exists in the project root, the CLI uses it. Otherwise it applies these defaults: entry points `src/main.ts` and `spraxium.config.ts`, output directory `.spraxium/dist`, format ESM, platform Node, `--clean`, and `--no-dts`.
83+
Runs `tsdown` with your project's configuration. If a `tsdown.config.*` file
84+
exists in the project root, the CLI uses it. Otherwise it applies these
85+
defaults: entry points `src/main.ts` and `spraxium.config.ts`, output
86+
directory `.spraxium/dist`, format ESM, platform Node, `--clean`, and
87+
`--no-dts`.
7488
</Step>
7589
</Steps>
7690

77-
The compiled output lands in `.spraxium/dist/` by default. This directory is the artifact that *spraxium start* looks for.
91+
The compiled output lands in `.spraxium/dist/` by default. This directory is the artifact that _spraxium start_ looks for.
7892

7993
<Callout tone="warning" title="Build does not run tests">
80-
Running *spraxium build* does not execute your test suite. Run your tests separately before or after, and treat the build as a type and bundle gate only.
94+
Running *spraxium build* does not execute your test suite. Run your tests
95+
separately before or after, and treat the build as a type and bundle gate
96+
only.
8197
</Callout>
8298

8399
---
84100

85101
## spraxium start
86102

87-
*spraxium start* runs the compiled artifact produced by *spraxium build*. It sets `NODE_ENV=production` before launching and inherits the current process stdio so application logs stream directly to the terminal.
103+
_spraxium start_ runs the compiled artifact produced by _spraxium build_. It sets `NODE_ENV=production` before launching and inherits the current process stdio so application logs stream directly to the terminal.
88104

89105
```bash filename="terminal"
90106
spraxium start
@@ -102,14 +118,16 @@ The CLI checks the following paths in order and runs the first one it finds:
102118
6. `build/main.js`
103119

104120
<Callout tone="warning" title="No build means no start">
105-
If none of the candidate paths exist, the command fails and prints a message telling you to run *spraxium build* first. Ensure your environment variables such as DISCORD_TOKEN are loaded before running this command.
121+
If none of the candidate paths exist, the command fails and prints a message
122+
telling you to run *spraxium build* first. Ensure your environment variables
123+
such as DISCORD_TOKEN are loaded before running this command.
106124
</Callout>
107125

108126
---
109127

110128
## Typical workflow
111129

112-
A complete iteration from development to production follows this order: run *spraxium dev* during active work, then switch to *spraxium build* when preparing a release, and finally run *spraxium start* to verify or deploy the compiled artifact. In CI, skip the dev step entirely and run build then start in sequence as your validation pipeline.
130+
A complete iteration from development to production follows this order: run _spraxium dev_ during active work, then switch to _spraxium build_ when preparing a release, and finally run _spraxium start_ to verify or deploy the compiled artifact. In CI, skip the dev step entirely and run build then start in sequence as your validation pipeline.
113131

114132
## Next page
115133

0 commit comments

Comments
 (0)