fix(plugin): include property if using @Matches with chained expression

[quangtran88]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

When utilizing the @Matches decorator with a chained expression as the first argument, the associated property is not included in the _OPENAPI_METADATA_FACTORY. Consequently, this omission leads to the property being absent in the generated Swagger schema.

Issue Number: #2723

What is the new behavior?

The property decorated with @Matches with a chained expression as the first argument, should now be properly defined in the generated Swagger schema. This resolves the issue of missing properties in the Swagger documentation.

Does this PR introduce a breaking change?

• Yes
• No

Other information

The root cause lies in the following line:

swagger/lib/plugin/visitors/model-class.visitor.ts

Line 673 in 33bec34

createPrimitiveLiteral(factory, head(decoratorArguments).text)

When the first argument is a chained expression, head(decoratorArguments).text resolves to undefined. To address this issue, we can use the getText() method for a safer extraction of the pattern information passed in the first argument. For example:

• @Matches(a.b.c) will resolve as "a.b.c" (instead of undefined using .text)
• @Matches(a) will resolve as "a" (same as using .text)
• @Matches(/^[+]?abc$/) will resolve as "/^[+]?abc$/" (same as using .text)

[micalevisk]

can you show an example of how the swagger UI would look like?

[quangtran88]

can you show an example of how the swagger UI would look like?

Given below model:

export const DemoValidation = {
  a: {
    b: /^abc$/,
    c: { d: /^abc$/ },
    e: [/^abc$/],
  },
};

const PATTERN = /^abc$/;

export class CreateDemoDto {
  @IsString()
  @Matches(DemoValidation.a.b)
  name: string;

  @IsString()
  @Matches(DemoValidation.a.c.d)
  name_1: string;

  @IsString()
  @Matches(DemoValidation.a.e[0])
  name_2: string;

  @IsString()
  @Matches(/^abc$/)
  name_3: string;

  @Matches(PATTERN)
  @IsOptional()
  name_4: string;
}

The swagger will be generated as:

[micalevisk]

I like the ideia but it also feels like we are leaking internal info

Can't we expose the regex (ie, the pattern itself) instead of a 'label'? 🤔

[okonon]

Running into same issues that this PR fixes. Thanks for the all the work guys

[okonon]

@micalevisk @quangtran88 are there any remaining to-dos to get this merged besides resolving conflicts ?

[quangtran88]

I have successfully resolved the conflicts, thanks to @okonon. Upon further investigation, I discovered that this plugin generates Swagger metadata during the compilation of the source code. Consequently, obtaining the actual value at this stage is not feasible. I believe the focus for addressing this issue should be on fixing the missing property error. As for the new feature proposed by @micalevisk, it requires a more in-depth investigation and additional effort. It would be advisable to open a separate issue for this. What are your thoughts on this, @micalevisk?

[micalevisk]

A new issue to report that seems good