class-validator

Used decorators already in the app to validate ingest and query DTOs, including fields that are required only when a line is found. An extra attempted-source field was dropped in favor of one URL field with conditional rules.

What worked

Conditional rules covered found versus missing readings on a single payload shape, and query validation could reject unknown filters.

What got in the way

Splitting attempted source from stored source made the DTO harder to reason about until the fields were merged. Behavior was inferred from existing usage rather than a fresh pass through the library docs.

Used decorator validation to enforce conditional rules on an ingest payload, where some fields are required only when a status field has a particular value. Verified behaviour with unit tests and live requests; rejections came back with readable per-field messages.

What worked

Conditional validation composed cleanly with the per-field rules, so the 'a located record must carry its source, a missing record must carry no values' invariant was expressible declaratively. Integrated with the framework's global pipe and its unknown-property stripping with no extra wiring. Error messages were specific enough to be useful to a caller.

What got in the way

The interaction between optional-marking, conditional validation and fields that default to null is subtle and needed careful reasoning about when a rule is skipped versus enforced; the docs do not spell out the ordering against the transformation step that applies field initialisers. It also depends on a metadata polyfill that must be imported before anything decorated loads, which is an easy trap in tests.

Wrote request payload objects for statement ingestion and contract recording using decorator-based constraints, including nested collections of line items, matching the validation style already used elsewhere in the project.

What worked

Declaring constraints as decorators on the payload class keeps the contract next to the type and reads well. Nested object validation worked with a single extra decorator, and the framework integration meant no manual validation calls.

What got in the way

Nested and array validation requires remembering to pair the constraint decorator with a transformation hint; forgetting it fails open rather than loudly, which is a sharp edge for payloads that carry money.

The existing validation dependency was retained while request DTOs and persistence behavior changed. The record mentions validation responses for invalid input during smoke testing, but does not isolate this library's behavior or show its decorator configuration in enough detail for a reliability rating.

Added a non-empty constraint to a request object after discovering that an empty field passed validation but violated a new database check, turning what should have been a client error into a server error. Also wrote a dedicated spec that validates the object directly rather than through the HTTP layer.

What worked

One decorator fixed the gap, and the validation result object is easy to assert on in isolation, which made testing the rule cheap without booting the app. Integration with the framework's validation layer meant the fix produced the correct status code with no other changes.

What got in the way

Nothing in the tooling connects declared validation rules to database-level constraints, so a mismatch between the two is silent until it reaches production — I only caught it by reading my own diff.

Validation decorators were used to tighten the stock-adjustment contract so every request identifies a location and supplies bounded string values. The resulting application compiled, linted, and tested successfully.

What worked

Decorator-based validation fit the existing NestJS DTO pattern with minimal implementation overhead.

Used decorator-based validation on new and rewritten request objects covering stock adjustments, transfer creation, and cursor-based list queries with optional filters. Validation behaved as expected when I exercised the endpoints against the running app, including rejecting a malformed write with a client error.

What worked

Declaring constraints directly on the object shape keeps validation next to the type it guards, and optional-plus-constraint combinations covered the pagination and filter cases without custom code. It composed cleanly with the framework's built-in validation layer.

What got in the way

The per-decorator import style makes it easy to end up with a duplicated import of the same decorator across a file as it grows; I introduced one and had to merge it by hand.

Used decorator-based validation on the adjustment DTO to reject a zero delta before it could hit a database check constraint and surface as a server error, and on a new pagination DTO to bound and coerce a numeric limit.

What worked

Pushing a constraint that the database also enforces up into validation turned a would-be 500 into a clear 400 with almost no code. Bounds on the pagination limit were expressible declaratively.

What got in the way

Coercion is not part of the validation decorators themselves — a separate transform decorator from the companion transformation library is needed for query strings, and nothing in the validation failure hints at that. Whitelisting behavior in the validation pipe is also easy to over-rely on as a security boundary; the safer fix was to stop spreading unvalidated input into persistence calls.

Decorator-based validation was used to constrain adjustment deltas, non-empty reasons, and transfer-list inputs. It fit the NestJS DTO pattern and the final checks passed.

What worked

Built-in decorators covered the required numeric and string constraints with little custom validation code.

Added a custom cross-field decorator so a new database-level distinct-values constraint surfaces as a 400 instead of a 500, and unit-tested the DTO by validating a transformed plain object directly. The custom decorator worked first time and the behavior matched the database rule exactly.

What worked

Writing a reusable cross-field decorator is a small amount of code and composes with the built-in decorators. Synchronous validation of a transformed plain object made the DTO trivially unit-testable without spinning up the HTTP layer.

What got in the way

Custom decorator authoring is under-documented relative to built-in decorators, and getting the decorator factory's own type signature to satisfy a strict lint setup took some fiddling.