eslint-plugin-nestjs-typed

This rule enforces alphabetical ascending order for arrays within NestJS @Module decorators. It also sorts Call Expressions used within these arrays (e.g., MyModule.forRoot(...)).

Note on existing projects: The rule processes one entry at a time. If you enable this on an existing project, you may need to run the ESLint --fix command multiple times to fully sort large arrays. Once sorted, it will warn you as you add new items out of order.

// This will FAIL because AuthzModule is at the end instead of the beginning
@Module({
    imports: [
        CoreModule,
        DatabaseModule,
        OpenTelemetryModule.forRoot({
            metrics: { hostMetrics: true, apiMetrics: { enable: true } },
        }),
        UserInternalModule,
        AuthzModule,
    ],
    controllers: [AController, BController],
    providers: [AProvider, BProvider],
})
export class MainModule {}

// This will PASS because arrays are alphabetical ASC
@Module({
    imports: [
        AuthzModule,
        CoreModule,
        DatabaseModule,
        OpenTelemetryModule.forRoot({
            metrics: { hostMetrics: true, apiMetrics: { enable: true } },
        }),
        UserInternalModule,
    ],
    controllers: [AController, BController],
    providers: [AProvider, BProvider],
})
export class MainModule {}

The param-decorator-name-matches-route-param rule ensures that the name provided to a @Param("name") decorator matches a corresponding URL parameter defined in either a @Controller() decorator or a method decorator (such as @Get() or @Post()).

Limitations

• Regex Params: The rule does not support NestJS fuzzy matching regex parameters (e.g., _+?()*). Routes containing these characters are ignored.
• String Types: The rule only supports single or double-quoted strings. It does not support variables or template strings for route definitions.

Correct Usage Patterns

1. Parameter defined in the method decorator:

@Controller("custom-bot")
export class CustomBotController {
    @Get(":uuid")
    findOne(@Param("uuid") uuid: string) {
        // ...
    }
}

2. Parameter defined in the controller decorator:

@Controller("custom-bot/:uuid")
export class CustomBotController {
    @Get()
    findOne(@Param("uuid") uuid: string) {
        // ...
    }
}

Common Errors to Avoid

1. Typos in the decorator name: If the @Param("name") does not exactly match the string in the route (e.g., @Param("uui") for a :uuid route), the rule will fail.

2. Including the colon (:) in the @Param decorator: In NestJS, the colon is used in the route string to indicate a parameter, but it should not be included inside the @Param() decorator.

• ❌ Incorrect: @Param(":uuid")
• ✅ Correct: @Param("uuid")

@Controller("custom-bot")
export class CustomBotController {
    @Get(":uuid")
    findOne(@Param("uuid") uuid: string) {
        return this.customBotService.findOne(uuid);
    }
}

In ESM (ECMAScript Modules) applications, using a class as both the forwardRef() target and the constructor parameter type can cause the class to be evaluated before its module has fully initialized. This rule enforces the use of a wrapper type for the constructor parameter to prevent the direct class reference from being emitted as decorator metadata.

To fix this, define a generic wrapper type (e.g., WrapperType<T> = T) and use it for the parameter type instead of the class itself. Alternatively, the best long-term solution is to refactor the code to remove the circular dependency.

This rule is enabled by default in the recommended configuration.

// Define a wrapper type
export type WrapperType<T> = T;

// Use the wrapper type in the constructor to pass the lint rule
constructor(
  @Inject(forwardRef(() => ProfileService))
  private readonly profileService: WrapperType<ProfileService>,
) {}

The all-properties-have-explicit-defined rule ensures that every property in a class intended for validation has an explicit validation presence decorator: @IsDefined(), @IsOptional(), or @ValidateIf().

Key behaviors:

• Conflict Prevention: It prevents invalid combinations such as @IsDefined() with @IsOptional(), or @IsOptional() with @ValidateIf().
• Valid Patterns: Combining @ValidateIf() with @IsDefined() is permitted for conditional validation on optional properties.
• Automatic Exclusion: To prevent false positives on non-validation classes, the rule ignores any class that contains zero class-validator decorators.

// PASSES - all properties are decorated correctly
export class CreateOrganisationDto {
    @IsDefined()
    otherProperty!: MyClass;

    @IsOptional()
    someStringProperty?: string;

    @ValidateIf(o => !o.someStringProperty)
    @Length(10, 20)
    someOtherProperty?:  string
}

// FAILS - missing @IsOptional() or @ValidateIf() on someStringProperty
export class CreateOrganisationDto {
    @IsDefined()
    otherProperty!: MyClass;
    @IsString()
    someStringProperty?: string;
}