New behavior in v6 when interface extends two incompatible interfaces under exactOptionalPropertyTypes

🔎 Search Terms

Partial, @types/node, exactOptionalPropertyTypes, interface

🕗 Version & Regression Information

This changed between versions v5.9.3 and 6.0.0-dev.20251001

⏯ Playground Link

https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true&ts=6.0.0-dev.20251008#code/HYQwtgpgzgDiDGEAEALALmmSDeBYAUEkhAB4wD2ATmkgJbBoSUBmCyAKvDAMrnwDWENAGFywYBHhoA8jDRQcBIkQrUAXEmABXMACMmAbiVIAvgWOlVNeoxZskAQQDmEBrLS0xC0o2AATBQAFEGpaEAAbAB5OHj5BETEJKXcoAD5FQmVBCBgHcNoANwgAfg1dcnJwiBBgJAAfJC1-CGZ6CD8jTLN8boJQSFh7NHCFPEzLKmsGJlZEJFFxSQ8xd09gUeMVSdLNHX1Kesbm1okO427e-BsZ+2dXGTk17xJfANQMGAA6O7dHrwAaJDDKCfBZJZbAVZeDJEMAgEjCBAodrcaBQJ47bR6JiHJp+FptM49AhAA

💻 Code

namespace http {
  export interface TcpSocketConnectOpts {
    port: number;
  }

  export interface AgentOptions extends Partial<TcpSocketConnectOpts> {
    keepAlive?: boolean | undefined;
  }
}

namespace tls {
  export interface ConnectionOptions {
    port?: number | undefined;
  }
}

interface AgentOptions extends http.AgentOptions, tls.ConnectionOptions {
  maxCachedSessions?: number | undefined;
}

🙁 Actual behavior

This now fails to type check—I believe correctly, because Partial<{ port: number }> is { port?: number }, not { port?: number | undefined }. It’s surprising that this worked before.

🙂 Expected behavior

Actually, the new behavior is expected, so probably @types/node needs an update. I wanted to flag this in case/for when other folks hit it!

Additional information about the issue

Happens on latest @types/node.
Discovered via True Myth’s nightly TS@next CI job as well as dependabot upgrades that test. The semver-ts.org guidance to test against upcoming versions is: good!

infra: temporarily disable `exactOptionalPropertyTypes`

bisects to #61683

Probably this means we need to add yet another tsconfig variant to the node types to test this. But perhaps we should simply revert that PR...

I think we're better off just testing with exactOptionalPropertyTypes ubiquitously. We intend to be compatible with it, so is there any added value in testing without it as well?

Probably not... (When it's not 4am for me I intend to hack dtslint to force this option on and see how bad things are in DT)

Thanks for the report on this!

Based on the label, we agree this is a bug in the types, yes? So DT has to be fixed?

Yep

Jake Bailey (@jakebailey)

Confirmed resolved with @types/node@24.7.1. Closing this accordingly. Thanks for hopping on it in the types so quickly Jake Bailey (@jakebailey) and for writing a test for it Mateusz Burzyński (@Andarist)! Appreciate you folks.

Navigation Menu

Repository navigation

New behavior in v6 when interface extends two incompatible interfaces under exactOptionalPropertyTypes #62569

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Additional information about the issue

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

New behavior in v6 when interface extends two incompatible interfaces under exactOptionalPropertyTypes #62569

Description

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Additional information about the issue

Activity

Andarist commented on Oct 9, 2025

jakebailey commented on Oct 9, 2025

Renegade334 commented on Oct 9, 2025

jakebailey commented on Oct 9, 2025

RyanCavanaugh commented on Oct 9, 2025

jakebailey commented on Oct 9, 2025

RyanCavanaugh commented on Oct 9, 2025

chriskrycho commented on Oct 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions