@ftisindia/create-app 0.1.1 → 0.1.3

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 CHANGED
@@ -92,3 +92,68 @@ add a module and the architecture rules.
92
92
  Released under the **PolyForm Noncommercial License 1.0.0** — free for any noncommercial
93
93
  use. **Commercial use requires a separate commercial license from
94
94
  [ftisindia.com](https://ftisindia.com).** See the bundled `LICENSE` file.
95
+
96
+ ## Generating a module with `gen:module`
97
+
98
+ Every project this CLI generates ships a `gen:module` script. In any generated project,
99
+ run it to scaffold a new feature module that already follows the project's auth, RBAC,
100
+ request-context, and audit conventions.
101
+
102
+ ```bash
103
+ npm run gen:module -- billing
104
+ ```
105
+
106
+ > Note the `--` before the name — it tells npm to pass the argument through to the
107
+ > generator. Names are normalized automatically, so `billing`, `Billing`,
108
+ > `"invoice items"`, and `invoiceItems` all resolve to the same module.
109
+
110
+ ### What it generates
111
+
112
+ For a name like `billing`, you get:
113
+
114
+ - `src/modules/billing/billing.module.ts` — the NestJS module (wires controller + service)
115
+ - `src/modules/billing/dto/billing-echo.dto.ts` — a sample DTO (class-validator + Swagger)
116
+ - `src/modules/billing/application/services/billing.service.ts` — a service with
117
+ `getStatus()` and `echo()` that use Prisma, request context, and write an audit-log row
118
+ - `src/modules/billing/presentation/billing.controller.ts` — an org-scoped controller
119
+ guarded by `JwtAuthGuard`, `OrgScopeGuard`, and `PermissionGuard`, exposing:
120
+ - `GET /organisations/:orgId/billing/status` — requires `billing.read`
121
+ - `POST /organisations/:orgId/billing/echo` — requires `billing.update`
122
+ - `test/billing.spec.ts` — a starter unit test
123
+
124
+ It also keeps RBAC in sync automatically by appending to:
125
+
126
+ - `src/modules/access-control/types/permission-key.ts` — adds `billing.read` and `billing.update`
127
+ - `src/modules/access-control/types/route-permission-registry.ts` — adds the two route
128
+ entries (startup and tests fail if a guarded route is missing here)
129
+
130
+ The generator never overwrites existing files — it stops if any target already exists.
131
+
132
+ ### Two steps to finish
133
+
134
+ 1. **Register the module** in `src/app.module.ts` (the generator prints this reminder):
135
+ ```ts
136
+ import { BillingModule } from './modules/billing/billing.module';
137
+ // add BillingModule to the @Module({ imports: [...] }) array
138
+ ```
139
+ 2. **Re-seed permissions** so the new keys exist in the database and can be granted to roles:
140
+ ```bash
141
+ npm run prisma:seed
142
+ ```
143
+ Then assign `billing.read` / `billing.update` to the appropriate role(s).
144
+
145
+ Start the app and the new guarded endpoints are live (visible in Swagger at `/docs`).
146
+
147
+ ### When not to use it
148
+
149
+ - **You need a non-org-scoped or public route.** The output is hard-wired to
150
+ `/organisations/:orgId/<name>` with the org guards. Build global/unauthenticated
151
+ endpoints by hand instead.
152
+ - **You're extending an existing module.** It scaffolds a brand-new module and refuses
153
+ to overwrite — add files to the existing module manually.
154
+ - **Your feature doesn't map to simple read/update permissions.** It generates exactly
155
+ `<name>.read` and `<name>.update`; for richer permission sets, edit the generated
156
+ `permission-key.ts` and registry entries afterward.
157
+ - **You want a different shape than the `status` + `echo` reference endpoints.** Treat
158
+ the output as a starting point, or copy `src/modules/sample` (see
159
+ `docs/SAMPLE_MODULE.md`) for a fuller reference.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ftisindia/create-app",
3
- "version": "0.1.1",
3
+ "version": "0.1.3",
4
4
  "description": "One-command scaffolder for the Phase 1 NestJS foundation starter.",
5
5
  "type": "module",
6
6
  "bin": {
@@ -144,3 +144,67 @@ Swagger is mounted at `/docs` and includes tags, request schemas, response DTOs,
144
144
  common error responses, bearer authorization, route parameters, and examples for
145
145
  all implemented API routes. See `docs/API_REFERENCE.md` before adding or changing
146
146
  controllers.
147
+
148
+ ## Generating a module with `gen:module`
149
+
150
+ Scaffold a new feature module that already follows the project's auth, RBAC,
151
+ request-context, and audit conventions.
152
+
153
+ ```bash
154
+ npm run gen:module -- billing
155
+ ```
156
+
157
+ > Note the `--` before the name — it tells npm to pass the argument through to the
158
+ > generator. Names are normalized automatically, so `billing`, `Billing`,
159
+ > `"invoice items"`, and `invoiceItems` all resolve to the same module.
160
+
161
+ ### What it generates
162
+
163
+ For a name like `billing`, you get:
164
+
165
+ - `src/modules/billing/billing.module.ts` — the NestJS module (wires controller + service)
166
+ - `src/modules/billing/dto/billing-echo.dto.ts` — a sample DTO (class-validator + Swagger)
167
+ - `src/modules/billing/application/services/billing.service.ts` — a service with
168
+ `getStatus()` and `echo()` that use Prisma, request context, and write an audit-log row
169
+ - `src/modules/billing/presentation/billing.controller.ts` — an org-scoped controller
170
+ guarded by `JwtAuthGuard`, `OrgScopeGuard`, and `PermissionGuard`, exposing:
171
+ - `GET /organisations/:orgId/billing/status` — requires `billing.read`
172
+ - `POST /organisations/:orgId/billing/echo` — requires `billing.update`
173
+ - `test/billing.spec.ts` — a starter unit test
174
+
175
+ It also keeps RBAC in sync automatically by appending to:
176
+
177
+ - `src/modules/access-control/types/permission-key.ts` — adds `billing.read` and `billing.update`
178
+ - `src/modules/access-control/types/route-permission-registry.ts` — adds the two route
179
+ entries (startup and tests fail if a guarded route is missing here)
180
+
181
+ The generator never overwrites existing files — it stops if any target already exists.
182
+
183
+ ### Two steps to finish
184
+
185
+ 1. **Register the module** in `src/app.module.ts` (the generator prints this reminder):
186
+ ```ts
187
+ import { BillingModule } from './modules/billing/billing.module';
188
+ // add BillingModule to the @Module({ imports: [...] }) array
189
+ ```
190
+ 2. **Re-seed permissions** so the new keys exist in the database and can be granted to roles:
191
+ ```bash
192
+ npm run prisma:seed
193
+ ```
194
+ Then assign `billing.read` / `billing.update` to the appropriate role(s).
195
+
196
+ Start the app and the new guarded endpoints are live (visible in Swagger at `/docs`).
197
+
198
+ ### When not to use it
199
+
200
+ - **You need a non-org-scoped or public route.** The output is hard-wired to
201
+ `/organisations/:orgId/<name>` with the org guards. Build global/unauthenticated
202
+ endpoints by hand instead.
203
+ - **You're extending an existing module.** It scaffolds a brand-new module and refuses
204
+ to overwrite — add files to the existing module manually.
205
+ - **Your feature doesn't map to simple read/update permissions.** It generates exactly
206
+ `<name>.read` and `<name>.update`; for richer permission sets, edit the generated
207
+ `permission-key.ts` and registry entries afterward.
208
+ - **You want a different shape than the `status` + `echo` reference endpoints.** Treat
209
+ the output as a starting point, or copy `src/modules/sample` (see
210
+ `docs/SAMPLE_MODULE.md`) for a fuller reference.
@@ -6,6 +6,7 @@
6
6
  "emitDecoratorMetadata": true,
7
7
  "experimentalDecorators": true,
8
8
  "allowSyntheticDefaultImports": true,
9
+ "esModuleInterop": true,
9
10
  "target": "ES2023",
10
11
  "sourceMap": true,
11
12
  "outDir": "./dist",