Unexpected parent path when use ValidationPipe for nested object

[shenX-2021]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When I set a custom message for nested object validation, the final error message has a prefix parent path which is not expected.

Below is my Validation code.

Minimum reproduction code

https://github.com/shenX-2021/nestjs-validation-issue

Steps to reproduce

1. npm ci
2. npm run start:dev
3. curl --location --request GET 'http://localhost:3000' --header 'Content-Type: application/json' --data '{"parent": {},"text": 123}'

Expected behavior

When I set message in ValidationOptions, I expect the final error message is same with I set.

NestJS version

11.0.1

Packages versions

{
  "dependencies": {
    "@nestjs/common": "^11.0.1",
    "@nestjs/core": "^11.0.1",
    "@nestjs/platform-express": "^11.0.1",
    "class-transformer": "^0.5.1",
    "class-validator": "^0.14.3",
    "reflect-metadata": "^0.2.2",
    "rxjs": "^7.8.1"
  },
  "devDependencies": {
    "@eslint/eslintrc": "^3.2.0",
    "@eslint/js": "^9.18.0",
    "@nestjs/cli": "^11.0.0",
    "@nestjs/schematics": "^11.0.0",
    "@nestjs/testing": "^11.0.1",
    "@types/express": "^5.0.0",
    "@types/jest": "^30.0.0",
    "@types/node": "^22.10.7",
    "@types/supertest": "^6.0.2",
    "eslint": "^9.18.0",
    "eslint-config-prettier": "^10.0.1",
    "eslint-plugin-prettier": "^5.2.2",
    "globals": "^16.0.0",
    "jest": "^30.0.0",
    "prettier": "^3.4.2",
    "source-map-support": "^0.5.21",
    "supertest": "^7.0.0",
    "ts-jest": "^29.2.5",
    "ts-loader": "^9.5.2",
    "ts-node": "^10.9.2",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.7.3",
    "typescript-eslint": "^8.20.0"
  }
}

Node.js version

24.13.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

I think it is good idea that adding parent path for the default error message. But I prefer it is implemented in class-validator than nestjs.

I found relative PR for this change. FYI.
https://github.com/nestjs/nest/pull/5863/changes

[at7211]

@shenX-2021
As a quick workaround, you can use the existing exceptionFactory option to fully control how validation errors are formatted. This bypasses the built-in flattenValidationErrors which prepends the parent path to your custom messages.

For example

import { BadRequestException, ValidationPipe } from '@nestjs/common';                                                                                                
import { ValidationError } from 'class-validator';                                                                                                                   
                                                                                                                                                                     
app.useGlobalPipes(new ValidationPipe({                                                                                                                              
  exceptionFactory: (errors: ValidationError[]) => {   
    // implement custom logic                                                                 
    const result: Record<string, string[]> = {};                                                                                                                     
    const extractErrors = (errs: ValidationError[], parentPath = '') => {                                                                                            
      for (const err of errs) {                                                                                                                                      
        const path = parentPath                                                                                                                                      
          ? `${parentPath}.${err.property}`                                                                                                                          
          : err.property;                                                                                                                                            
        if (err.constraints) {                                                                                                                                       
          result[path] = Object.values(err.constraints);                                                                                                             
        }                                                                                                                                                            
        if (err.children?.length) {                                                                                                                                  
          extractErrors(err.children, path);                                                                                                                         
        }                                                                                                                                                            
      }                                                                                                                                                              
    };                                                                                                                                                               
    extractErrors(errors);                                                                                                                                           
    return new BadRequestException(result);                                                                                                                          
  },                                                                                                                                                                 
}));  

Result

{
    "parent.child": [
        "parameter child can not be empty",
        "child must be a string"
    ],
    "text": [
        "text must be a string"
    ]
}

Custom messages are preserved as-is, and the property path is expressed through the object keys instead.

[kamilmysliwiec]

Would you like to create a PR for this issue?

[at7211]

@kamilmysliwiec
Sure, I'd be happy to create a PR for this.

My plan is to add a new errorFormat option to ValidationPipeOptions:

• 'list' (default) — current behavior, backward compatible
• 'grouped' — returns Record<string, string[]> with property paths as keys and unmodified constraint messages as values

This way users who want the grouped format (like the workaround above) can simply set errorFormat: 'grouped' without implementing their own exceptionFactory.

Does this direction sound good, or would you prefer a different approach?

[kamilmysliwiec]

Let's track this here #16329