@tahminator/sapling 2.0.4 → 2.0.5-beta.18ab8bae

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
@@ -200,12 +200,71 @@ class UserController {
200
200
  }
201
201
  ```
202
202
 
203
- Make sure to register an error handler middleware:
203
+ Sapling ships with default error middlewares, and you can also write your own.
204
+ Register error middlewares after your regular middlewares and controllers:
204
205
 
205
206
  ```typescript
206
- Sapling.loadResponseStatusErrorMiddleware(app, (err, req, res, next) => {
207
- res.status(err.status).json({ error: err.message });
208
- });
207
+ import {
208
+ DefaultBaseErrorMiddleware,
209
+ DefaultResponseStatusErrorMiddleware,
210
+ } from "@tahminator/sapling";
211
+
212
+ // regular middlewares & controllers first
213
+ const middlewares: Class<any>[] = [CookieParserMiddleware];
214
+ middlewares.map(Sapling.resolve).forEach((r) => app.use(r));
215
+
216
+ const controllers: Class<any>[] = [UserController];
217
+ controllers.map(Sapling.resolve).forEach((r) => app.use(r));
218
+
219
+ // error middlewares last
220
+ const errorMiddlewares: Class<any>[] = [
221
+ DefaultResponseStatusErrorMiddleware,
222
+ DefaultBaseErrorMiddleware,
223
+ ];
224
+ errorMiddlewares.map(Sapling.resolve).forEach((r) => app.use(r));
225
+ ```
226
+
227
+ You can also write your own error middlewares. A specific handler should call
228
+ `next(err)` when it does not handle the error, and a base handler should be last
229
+ and return a response:
230
+
231
+ ```typescript
232
+ @MiddlewareClass()
233
+ class ResponseStatusErrorMiddleware {
234
+ @Middleware()
235
+ handle(
236
+ err: unknown,
237
+ _request: Request,
238
+ _response: Response,
239
+ next: NextFunction,
240
+ ) {
241
+ if (err instanceof ResponseStatusError) {
242
+ return ResponseEntity.status(err.status).body({ message: err.message });
243
+ }
244
+
245
+ // MUST call next(err) to continue the chain
246
+ next(err);
247
+ }
248
+ }
249
+
250
+ @MiddlewareClass()
251
+ class BaseErrorMiddleware {
252
+ @Middleware()
253
+ handle(
254
+ err: unknown,
255
+ _request: Request,
256
+ _response: Response,
257
+ _next: NextFunction,
258
+ ) {
259
+ console.error("[Error]", err);
260
+
261
+ return ResponseEntity.status(500).body({
262
+ message: "Internal Server Error",
263
+ });
264
+
265
+ // no next(err) since last middleware in chain, we are done propagating
266
+ }
267
+ }
209
268
  ```
210
269
 
211
270
  ### Middleware
@@ -234,10 +293,41 @@ class CookieParserMiddleware {
234
293
  // Register it like any controller
235
294
  app.use(Sapling.resolve(CookieParserMiddleware));
236
295
 
296
+ // Register middlewares before controllers
297
+ app.use(Sapling.resolve(UserController));
298
+
237
299
  // You can also still choose to load plugins the Express.js way
238
300
  app.use(cookieParser());
239
301
  ```
240
302
 
303
+ You can also write custom middlewares as well. It is functionally the same way as Express: call `next()` explicitly to
304
+ continue down the chain:
305
+
306
+ ```typescript
307
+ import { MiddlewareClass, Middleware } from "@tahminator/sapling";
308
+ import { NextFunction, Request, Response } from "express";
309
+
310
+ @MiddlewareClass()
311
+ class RequestTimerMiddleware {
312
+ @Middleware()
313
+ handle(request: Request, _response: Response, next: NextFunction) {
314
+ const start = Date.now();
315
+
316
+ request.on("finish", () => {
317
+ const elapsedMs = Date.now() - start;
318
+ console.log(`[Request] ${request.method} ${request.path} ${elapsedMs}ms`);
319
+ });
320
+
321
+ // MUST call next() to continue the chain
322
+ next();
323
+ }
324
+ }
325
+
326
+ // Register middlewares before controllers
327
+ app.use(Sapling.resolve(RequestTimerMiddleware));
328
+ app.use(Sapling.resolve(UserController));
329
+ ```
330
+
241
331
  ### Request Validation
242
332
 
243
333
  Validate and transform request bodies, route params, and query strings at the controller level using `@RequestBody`, `@RequestParam`, and `@RequestQuery`. These decorators accept any [Standard Schema](https://github.com/standard-schema/standard-schema) compatible validator (Zod, Valibot, ArkType, etc.).