nodefony-framework-dev

In an application, run the CLI command nodefony create service <Nom> which scaffolds the class, its interface, and the @services wiring. In the framework repository, write a class extending Service with @injectable(), pass the module as first constructor parameter, and name dependencies explicitly with @inject since tsx does not emit design:paramtypes.

Create a Controller class and decorate methods with @Get, @Post, or @route from @nodefony/framework. WebSocket is a first-class transport on the same route table, session, and firewall as HTTP, so one controller action can serve both transports.

Any modification to @nodefony/http, @nodefony/framework, or the core pipeline requires the memory suite before committing. Blocking thresholds are 35 MB per 1000 HTTP requests, 10 MB per 100 crashes, and 30 MB per 100 WebSocket connections; exceeding them means fixing lazy allocation and listener cleanup first.

No, importing framework from http creates a circular dependency and is forbidden. The http package accesses framework-level objects like the resolver through the request context instead, using (context as any)?.resolver.

A command that reads or writes data must declare runProfile: CONSOLE_DATA_RUN_PROFILE so the framework connects the ORM. Without it, durable stores silently fall back to memory; the test is whether the command still makes sense when no database is running.

Time-threshold microbenchmarks are skipped by default because CPU variance and a loaded event loop make them unreliable in the full suite. They run only in isolation with NF_RUN_PERF=1, and thresholds must never be loosened to mask environment contamination.