Instantiate the pipe with an options object using new instead of passing the class reference. This lets you override the error HTTP status code, restrict UUID versions, or configure other pipe-specific behavior. When using new, the pipe is not resolved through DI — it cannot inject services.
Class reference (ParseIntPipe without new) — NestJS resolves it through the DI container.
Instance (new ParseIntPipe({...})) — you control options but lose DI injection inside the pipe.
Use class reference when the pipe has no options and may need injected services.
Use instance when you need to pass specific options like errorHttpStatusCode or version.
ParseFilePipe, ParseArrayPipe, ParseUUIDPipe, and ParseEnumPipe all accept option objects.
You need to accept a query parameter 'page' as an integer in a NestJS controller. How would you use ParseIntPipe to ensure it's parsed, and how would you set a default value of 1 if the client omits it?
A route expects a UUID path param 'id'. Show me how you'd apply ParseUUIDPipe with the version option set to '4'. What happens if the client sends an invalid UUID?
If you want ParseIntPipe to reject negative numbers, which option would you use and how would you configure it in the route decorator?
We have a GET endpoint that takes an optional 'limit' query param. The team wants to enforce that limit is between 1 and 100, default 20. How would you configure ParseIntPipe options to achieve this, and what would you do if the validation fails?
During a code review you notice a controller uses ParseUUIDPipe without specifying the version, and a bug appears when a client sends a version‑5 UUID. How would you fix it, and what trade‑offs are there in enforcing a specific version globally?
Our app uses a global ValidationPipe that also transforms numbers. A new requirement is to keep ParseIntPipe's custom error messages for certain routes. How would you pass custom error messages to ParseIntPipe while keeping the global pipe in place?
Design a strategy for handling numeric and UUID parameters across dozens of microservices, ensuring consistent validation and error handling. How would you leverage pipe options, custom pipes, or global configuration, and what are the performance implications?
We observed that using ParseIntPipe with the 'exceptionFactory' option adds overhead in high‑throughput endpoints. How would you evaluate the impact and decide whether to keep custom error factories or fallback to default behavior?
A legacy service parses IDs manually and sometimes returns 500 on malformed input. You need to migrate it to use ParseUUIDPipe with strict version checking without breaking existing clients. Outline the migration steps and how you'd handle backward compatibility.
Our platform plans to standardize request validation across all teams, including numeric, UUID, and custom formats. As a staff engineer, how would you define a shared library of pipes with preset options, versioning, and deprecation policy, and what governance processes would you put in place?
During a security audit it was discovered that some endpoints accept UUIDs without version constraints, potentially allowing injection attacks. How would you redesign the validation layer at the architectural level to enforce strict pipe options, and how would you roll this out across multiple services with minimal downtime?
Consider a scenario where you need to support both v1 and v2 API contracts, each requiring different parsing rules for IDs (v1 uses numeric IDs, v2 uses UUID v4). How would you structure your NestJS modules and pipe configurations to handle this divergence while keeping the codebase maintainable?