Why
The "Good: Post-Validation Assertion" example cites a file path and an invariant call that no longer exist, so a reader following the example to the source will find neither the path nor the assertion.
Current state
utils/errors/README.invariant.md lines 187–194 show:
// lib/cloudinary/fetchCloudinaryImageMetadata.ts
// Zod has already validated width/height are numbers
invariant(metadata.width > 0 && metadata.height > 0, 'Image dimensions must be positive', {
width: metadata.width,
height: metadata.height,
publicId,
})The file has moved to io/cloudinary/fetchCloudinaryImageMetadata.ts and no longer contains a dimensions invariant. The actual file validates and builds the metadata object directly from parseResult.data, then constructs CloudinaryImageMetadata without asserting positive dimensions at runtime.
Ideal state
- The example either references the current file path (
io/cloudinary/fetchCloudinaryImageMetadata.ts) with a call that actually exists there, or is replaced with a different example drawn from code that is present in the codebase.
- A reader can open the cited file and find the illustrative code.
Starting points
utils/errors/README.invariant.md — lines 184–194, the "Good: Post-Validation Assertion" blockio/cloudinary/fetchCloudinaryImageMetadata.ts — the actual current file (no dimensions invariant present)
QA plan
- Open
utils/errors/README.invariant.md and read the "Good: Post-Validation Assertion" example — expect the file path and invariant call to match code that exists in the repository.
- Open the cited file — expect to find the exact
invariant call shown in the example.
Done when
The example in README.invariant.md references a file path and invariant call that a reader can locate in the current codebase.
Why
The "Good: Post-Validation Assertion" example cites a file path and an
invariantcall that no longer exist, so a reader following the example to the source will find neither the path nor the assertion.Current state
utils/errors/README.invariant.mdlines 187–194 show:The file has moved to
io/cloudinary/fetchCloudinaryImageMetadata.tsand no longer contains a dimensionsinvariant. The actual file validates and builds themetadataobject directly fromparseResult.data, then constructsCloudinaryImageMetadatawithout asserting positive dimensions at runtime.Ideal state
io/cloudinary/fetchCloudinaryImageMetadata.ts) with a call that actually exists there, or is replaced with a different example drawn from code that is present in the codebase.Starting points
utils/errors/README.invariant.md— lines 184–194, the "Good: Post-Validation Assertion" blockio/cloudinary/fetchCloudinaryImageMetadata.ts— the actual current file (no dimensions invariant present)QA plan
utils/errors/README.invariant.mdand read the "Good: Post-Validation Assertion" example — expect the file path and invariant call to match code that exists in the repository.invariantcall shown in the example.Done when
The example in
README.invariant.mdreferences a file path andinvariantcall that a reader can locate in the current codebase.