@alevnyacow/nzmt 0.9.1 → 0.9.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +27 -21
- package/bin/cli.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -6,38 +6,44 @@
|
|
|
6
6
|
|
|
7
7
|
# About
|
|
8
8
|
|
|
9
|
-
NZMT is
|
|
9
|
+
NZMT is a scaffolding toolkit for building structured Next.js full-stack applications.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
It combines dependency injection, Zod validation and a DDD-inspired architecture,
|
|
12
|
+
while removing most of the boilerplate through code generation.
|
|
13
|
+
|
|
14
|
+
- 🧩 Generate entities, stores, services and controllers boilerplate **with simple CLI commands**.
|
|
12
15
|
- 🔐 **Runtime safety** across server layers with Zod out of the box.
|
|
13
16
|
- ⚡ **Dependency Injection** powered by Inversify with no setup required.
|
|
14
|
-
- 🚀 Comes with **scaffolding system** to generate and organize application structure via CLI.
|
|
15
17
|
|
|
16
|
-
# Quick start
|
|
18
|
+
# Quick start with Prisma
|
|
17
19
|
|
|
18
|
-
|
|
19
|
-
2. Install required peer dependencies (`inversify`, `zod`, `reflect-metadata`).
|
|
20
|
-
2. Enable `Experimental decorators` and `Emit Decorator Metadata` options in your `tsconfig.json`.
|
|
21
|
-
3. Run the following:
|
|
20
|
+
Suppose you have NextJS application with generated Prisma client.
|
|
22
21
|
|
|
22
|
+
1. Install required peer dependencies and the toolkit itself.
|
|
23
23
|
```bash
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
24
|
+
npm install inversify zod reflect-metadata @alevnyacow/nzmt
|
|
25
|
+
```
|
|
26
|
+
2. Enable `Experimental decorators` and `Emit Decorator Metadata` options in your `tsconfig.json`.
|
|
27
|
+
3. Initialize NZMT. This will set up all required infrastructure and configuration for you:
|
|
28
|
+
```bash
|
|
29
|
+
npx nzmt init prismaClientPath:@/app/generated/prisma/client
|
|
30
|
+
```
|
|
31
|
+
4. Scaffold your first entity. Example for a `Product` with `title` and `price`:
|
|
32
|
+
```bash
|
|
33
|
+
# Field syntax: f:<name>-<type>[.<zod-validators>]
|
|
28
34
|
npx nzmt entity product f:title-string,price-int.positive
|
|
29
|
-
|
|
35
|
+
```
|
|
36
|
+
This will generate the entity, its Zod schema and related types.
|
|
37
|
+
5. Scaffold server boilerplate
|
|
38
|
+
```bash
|
|
30
39
|
# product store (with Prisma implementation, RAM implementation and DI)
|
|
31
40
|
npx nzmt store product
|
|
32
|
-
|
|
33
41
|
# product service with injected product store (with DI)
|
|
34
42
|
npx nzmt service product i:ProductStore
|
|
35
|
-
|
|
36
43
|
# shop controller with injected product service and logger (with DI)
|
|
37
44
|
npx nzmt controller shop i:Logger,ProductService
|
|
38
45
|
```
|
|
39
|
-
|
|
40
|
-
The entire structure and infrastructure have been generated. All that remains is developing the contracts and the logic. The organization and content of the generated files are clear, and they’re easy to understand.
|
|
46
|
+
Now you have scaffolded structure for `ProductStore`, `ProductService` and `ShopController` and all of them are registered in the DI container. You can now implement your logic inside these modules and expose it via controllers.
|
|
41
47
|
|
|
42
48
|
You can use `fromDI` method anywhere you need an instance of a controller or a service:
|
|
43
49
|
|
|
@@ -47,8 +53,8 @@ You can use `fromDI` method anywhere you need an instance of a controller or a s
|
|
|
47
53
|
import type { ShopController } from "@/server/controllers/shop"
|
|
48
54
|
import { fromDI } from "@/server/di"
|
|
49
55
|
|
|
50
|
-
//
|
|
51
|
-
//
|
|
56
|
+
// The key is fully typed, so you get autocomplete
|
|
57
|
+
// across all registered DI modules.
|
|
52
58
|
const controller = fromDI<ShopController>('ShopController')
|
|
53
59
|
|
|
54
60
|
// Suppose you have implemented the list_GET method in the controller.
|
|
@@ -77,7 +83,7 @@ Server-side logic is structured into four core modules: *Stores*, *Services*, *C
|
|
|
77
83
|
|
|
78
84
|
There are also two building blocks shared across server and client: Entities and Value Objects.
|
|
79
85
|
|
|
80
|
-
- **Entities** represent domain objects used throughout the application. They
|
|
86
|
+
- **Entities** represent domain objects used throughout the application. They don’t include data access or business flow logic, but may contain pure domain logic, contracts and invariants (e.g. User, Product).
|
|
81
87
|
- **Value Objects** define reusable, strongly-typed invariants for meaningful concepts such as Pagination or Identifier.
|
|
82
88
|
|
|
83
89
|
# Scaffolding
|
|
@@ -85,7 +91,7 @@ There are also two building blocks shared across server and client: Entities and
|
|
|
85
91
|
## Setup
|
|
86
92
|
|
|
87
93
|
```
|
|
88
|
-
npx nzmt init prismaClientPath
|
|
94
|
+
npx nzmt init prismaClientPath:@/app/generated/prisma/client
|
|
89
95
|
```
|
|
90
96
|
This creates `nzmt.config.json`, sets up DI and testing, and adds base providers. `prismaClientPath:...` parameter is optional and enables Prisma scaffolding.
|
|
91
97
|
|
package/bin/cli.js
CHANGED
|
@@ -300,7 +300,7 @@ function initPrisma() {
|
|
|
300
300
|
|
|
301
301
|
fs.writeFileSync(path.resolve(prismaFolder, 'client.ts'), [
|
|
302
302
|
`import { PrismaPg } from '@prisma/adapter-pg'`,
|
|
303
|
-
`import { PrismaClient } from '
|
|
303
|
+
`import { PrismaClient } from '${prismaClientPath}'`,
|
|
304
304
|
``,
|
|
305
305
|
`const adapter = new PrismaPg({`,
|
|
306
306
|
`\tconnectionString: process.env.DATABASE_URL`,
|