Skip to content

Conversation

@bas0N
Copy link

@bas0N bas0N commented Nov 29, 2025

Closes #2182

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • 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 using ConfigService<Config, true> with a configuration type that includes optional fields (e.g., from Zod's .optional()), TypeScript does not emit type errors when assigning string | undefined to a strict string type.

This happens because the R type parameter in the get/getOrThrow overloads is inferred from contextual typing (the expected return type) instead of using the default PathValue<T, P>.

Example:

type Config = { API_KEY: string | undefined };

class Service {
  private apiKey: string;
  constructor(private config: ConfigService<Config, true>) {
    // Should error but doesn't!
    this.apiKey = this.config.get('API_KEY', { infer: true });
  }
}

Issue Number: #2182

What is the new behavior?

TypeScript now correctly emits type errors when assigning potentially undefined values to strict types, regardless of the WasValidated parameter.

The fix removes the R type parameter from the affected overloads and uses PathValue<T, P> directly in the return type, preventing contextual typing from overriding the correct type inference.

Does this PR introduce a breaking change?

  • Yes
  • No

The fix is compile-time only and does not change runtime behavior. Code that previously compiled without errors but was incorrectly typed will now show appropriate type errors, which is the expected/correct behavior.

Other information

Affected method overloads:

  • get(propertyPath, options)
  • get(propertyPath, defaultValue, options)
  • getOrThrow(propertyPath, options)
  • getOrThrow(propertyPath, defaultValue, options)

Added test file tests/e2e/type-inference-validated.spec.ts that uses @ts-expect-error to verify correct type inference behavior for both WasValidated = true and WasValidated = false cases

…ated

The R type parameter in get/getOrThrow overloads was being inferred from
contextual typing instead of using PathValue<T, P>. This caused TypeScript
to not emit errors when assigning potentially undefined values to strict
types when WasValidated was true.

Remove the R type parameter and use PathValue<T, P> directly to prevent
contextual typing from overriding the correct return type.

Closes nestjs#2182
@bas0N bas0N changed the title fix(common): correct type inference for optional fields with WasValid… fix(common): emit type errors for optional fields when WasValidated is true Nov 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TypeScript type checking inconsistency with ConfigService Zod validation

1 participant