Auto mocking is unsafe according to the linter.

[codiophile]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

The linter errors if you use auto mocking: https://docs.nestjs.com/fundamentals/testing#auto-mocking

src/app.controller.spec.ts
  22:17  error  Unsafe assignment of an `any` value            @typescript-eslint/no-unsafe-assignment
  23:11  error  Unsafe return of a value of type `any`         @typescript-eslint/no-unsafe-return
  23:18  error  Unsafe construction of a(n) `any` typed value  @typescript-eslint/no-unsafe-call

Minimum reproduction code

https://docs.nestjs.com/fundamentals/testing#auto-mocking

Steps to reproduce

1. Create new NestJS project
2. Add auto mocking to a test (https://docs.nestjs.com/fundamentals/testing#auto-mocking)
3. Run npm run lint

Expected behavior

Using code from the official documentation shouldn't cause the linter to fail. Either offer code that the linter is happy with or include instructions on which rules to disable and where, to keep the linter from complaining.

I don't know enough about how auto mocking works, to know if there is a type safe way of doing it, but that would be the ideal solution. If it is necessary to disable some rules, I would prefer if it is done in a way that doesn't affect the rest of the code.

Package

• I don't know. Or some 3rd-party package
• @nestjs/common
• @nestjs/core
• @nestjs/microservices
• @nestjs/platform-express
• @nestjs/platform-fastify
• @nestjs/platform-socket.io
• @nestjs/platform-ws
• @nestjs/testing
• @nestjs/websockets
• Other (see below)

Other package

No response

NestJS version

11.0.7

Packages versions

[System Information]
OS Version     : macOS24.5.0
NodeJS Version : v22.9.0
NPM Version    : 10.8.3 

[Nest CLI]
Nest CLI Version : 11.0.7 

[Nest Platform Information
platform-express version : 11.1.3
schematics version       : 11.0.5
testing version          : 11.1.3
common version           : 11.1.3
core version             : 11.1.3
cli version              : 11.0.7

Node.js version

No response

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[micalevisk]

I guess this is just a matter of updating that code example. Would you like to create a PR to address that at https://github.com/nestjs/docs.nestjs.com ?

[codiophile]

@micalevisk I wouldn't mind, but I don't know what it is supposed to be. I started experimenting with changing the anys, but haven't found anything that works. I was hoping that by reporting it, someone with knowledge might find a solution.

[codiophile]

Here's my solution for the time being:

const Mock = moduleMocker.generateFromMetadata(mockMetadata); // eslint-disable-line
return new Mock(); // eslint-disable-line

I don't love it, but I don't have a better solution.

[codiophile]

This seems to be a wider problem:

The suggested way of loading yaml config also makes the linter error:

import { readFileSync } from 'fs';
import * as yaml from 'js-yaml';
import { join } from 'path';

const YAML_CONFIG_FILENAME = 'config.yaml';

export default () => {
  return yaml.load(
    readFileSync(join(__dirname, YAML_CONFIG_FILENAME), 'utf8'),
  ) as Record<string, any>;
};

Source: https://docs.nestjs.com/techniques/configuration#custom-configuration-files

It again seems appropriate to use any, since you want this code to be able to load any generic yaml. Perhaps the "right" way is to define types for all of your configuration files and use those types when loading configuration. Regardless, this is not reflected in the documentation.

[micalevisk]

in this case I'd suggest just updating the default eslint config to disable those rules. It was not supposed to be strict like that

do you mind on updating it at https://github.com/nestjs/schematics/ and https://github.com/nestjs/typescript-starter/ ?

[codiophile]

@micalevisk In this case, I realised that I didn't have the js-yaml types installed.

npm i -D @types/js-yaml

Was all it took for the linter to stop complaining. My bad.

I'm a bit torn about whether the no-unsafe-* rules are too strict. It's definitely helped me find code that could have been better typed and prompted me to improve it.

I am currently migrating code from an old NestJS 10 project to a new NestJS 11 project. There's a new use case for the project that requires significant changes to the architecture and I figured it would be easier to start from a clean slate, set up the new architecture, and copy over the implementation, than to refactor it in place in the old project. By making the new project with NestJS 11, I kill two birds with one stone, as there's no separate migration to NestJS 11. However, it's taking me a lot longer than anticipated, due to the linter disliking the code that I'm copying over. While annoying, it's arguably improving the code quality.

[micalevisk]

to me, the @typescript-eslint/no-unused-vars and @typescript-eslint/no-unsafe-assignment are too strict to be in the boilerplate created by Nest CLI. I think that they are on now (as warn and error) because of a side-effect on upgrading eslint 🤔 it was not intentional

[codiophile]

@micalevisk I believe the main change is that you turned on the recommendedTypeChecked rules. I think the type checked rules are slower, so if we are disabling most of them, it might be worth disabling all of them. I haven't had a closer look. I was about to disable them, but decided to engage with the type system and fix the code instead.

[codiophile]

While trying to figure out how to type my manual mocks, I accidentally figured out how to type the auto mocks:

const Mock = moduleMocker.generateFromMetadata(
  mockMetadata,
) as ObjectConstructor;
return new Mock();

It was no harder than that. I think that is the right solution and I'm happy to update the documentation.