| name | add-nest-profiler-collector |
| description | Add one optional @eleven-labs/nest-profiler collector package to a NestJS app that already has the core profiler configured.
Matches the app's existing enable strategy and placement rules, and applies the collector's wiring gotcha.
Use when a project gains a new integration (TypeORM, MikroORM, Mongoose, HTTP client, cache, auth, config, GraphQL, class-validator/zod, nest-commander, RabbitMQ, routes) and the user wants its dedicated profiler panel.
|
Add a nest-profiler collector
Wire a single @eleven-labs/nest-profiler-* collector into an app whose core ProfilerModule is already set up. The references/collectors-matrix.md index maps a dependency to its collector and points at the family reference with the full options, snippet, gotcha and the question(s) to ask.
Core profiler not set up yet (no @eleven-labs/nest-profiler dependency, no ProfilerModule in the codebase)? → use the setup-nest-profiler skill instead; it installs the core and can add collectors in the same pass. A collector alone does nothing without the core.
Workflow
- Confirm the base setup — find the registered
ProfilerModule (or a ProfilingModule bundle) in the composition root and note the existing enable strategy: ConditionalModule.registerWhen(..., isProfilerEnabled) (Approach A) or the enabled flag (Approach B). Match it exactly — never introduce a second pattern. Reuse the app's existing isProfilerEnabled / env-condition helpers.
- Identify the collector — from the integration the user named or the new dependency in
package.json, look it up in references/collectors-matrix.md and open its family reference. Confirm the host lib is actually a dependency. If no @eleven-labs/nest-profiler-* package instruments it, say so — do not invent one (point to the custom-collector skill instead).
- Install —
<pm> add <collector-package> with the project's package manager (from the lockfile).
- Ask the collector's key question(s) — each family reference lists them (e.g. ORM: add the Schema panel? / HTTP: which client(s) to instrument? / validator: class-validator or zod?). Use
AskUserQuestion with header ≤ 12 chars.
- Place, gate, and apply the gotcha — put it where the matrix says (
config/validator/routes/commander at the root; database / http / cache / rabbitmq / graphql co-located with their host module) and gate it with the same strategy as the core. Collectors need no no-op counterpart. Key gotchas:
- TypeORM —
TypeOrmCollectorModule self-resolves the DataSource (via connectionName); no inject: [DataSource]. Add TypeOrmSchemaCollectorModule for the entity panel.
- MikroORM — ESM-only; import after
MikroOrmModule.
- HTTP — nothing is captured without an
instrumentations entry (AxiosInstrumentation from /axios, FetchInstrumentation from /fetch); axios needs HttpModule alongside.
- GraphQL — the module is
GraphQLCollectorModule; the context must expose the request.
- validator — replaces the global
ValidationPipe (remove any second one) and needs value imports of DTOs.
- commander — a cross-process store (
storageType: 'file', or the SQLite storage adapter — there is no storageType: 'sqlite') and imported in both the CLI and HTTP processes.
Verify
Start the app, exercise the instrumented subsystem (run a query, call an HTTP endpoint, hit a cached route…), open a fresh profile at /_profiler, and confirm the new collector panel appears with entries. Confirm the app still boots with profiling disabled.
