ts second args dont working

[productdevbook]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current behavior

Minimum reproduction code

https://github.com/productdevbook/nestjs_bug

Steps to reproduce

1. yarn install
2. go to vscode app.service.ts

Expected behavior

jwt.private etc typescript see. But dont see

Package version

2.1.0

NestJS version

8.4.6

Node.js version

v16.15.0

In which operating systems have you tested?

• [ ] macOS
• [ ] Windows
• [X] Linux

Other

No response

[micalevisk]

indeed. The type inference from ConfigService doesn't work with the latest version of typescript (v4.7.2), but it does in v4.6.3. Here's the demo of such:

https://user-images.githubusercontent.com/13461315/171713700-d38a9f2a-1b24-4f4d-bc4b-9b222ffddd85.mp4

I can't tell if it's a limitation or a bug tho

[kamilmysliwiec]

So it seems that the feature itself works as expected but the auto-complete is no longer useful, at least that's what I reproduced

[micalevisk]

yeah

I read the whole https://devblogs.microsoft.com/typescript/announcing-typescript-4-7 but I still don't understand why that didn't work anymore. Maybe it's related with Stricter Checks with Template String Expressions

[micalevisk]

I found another type utility for the dot notation type inference here

It does work but I didn't manage to make it work with ConfigService yet

[baconcheese113]

Thanks for all your work on this @micalevisk

Is there any chance of making infer: true the default value? Using dot-notation through a string value with autocomplete is a neat feature, but I wonder if it's worth the months of tech debt on this. It would be nice to simplify the interface to just

constructor(
    private readonly configService: ConfigService<AppConfig>,
) {
    const database = configService.get('database');
}

And still have database be typed correctly as an object with nested and port

[micalevisk]

@baconcheese113 it would introduce a breaking change. But yeah, we could change that in the next major release. I don't know why it is not the default behavior, tbh

[baconcheese113]

Oh additionally, we already validate the runtime value of our config object when registering the ConfigModule.

So it would be nice if configService.get would narrow the type based off the generic parameter instead of assuming all values can be undefined if not called with getOrThrow, maybe through some config we can provide to the ConfigModule?

[micalevisk]

@baconcheese113 that's not feasible in TS, if I understood you correctly

Please use our Discord server to discuss about it or other requests if you want to.