@types/node don't work with strictNullCheck enabled

[bajtos]

The type definition for HTTP response received by a client and HTTP request received by a server share the same interface, using optional properties to distinguish between those two types.

      export interface IncomingMessage extends stream.Readable 
        // [skipped]

        /**
         * Only valid for request obtained from http.Server.
         */
        method?: string;
        /**
         * Only valid for request obtained from http.Server.
         */
        url?: string;
        /**
         * Only valid for response obtained from http.ClientRequest.
         */
        statusCode?: number;
        /**
         * Only valid for response obtained from http.ClientRequest.
         */
        statusMessage?: string;

        // [etc.]
      }

This approach does not work when strictNullCheck is enabled in compiler options.

Consider the following code snippet:

import * as http from 'http';

http.createServer((req, res) => {
  const url: string = req.url;
  console.log(url);
});

The compiler reports the following error:

Type 'string | undefined' is not assignable to type 'string'.
  Type 'undefined' is not assignable to type 'string'. (2322)

• I tried using the @types/node package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @....

types/node/index.d.ts does not list any authors. The last two commits were made by @andy-ms and @kadler15

[thw0rted]

I think this SO answer makes a good point -- even though the Node docs describe this as a single class, it would probably be better to create separate interfaces for an IncomingMessage obtained from http.Server vs one obtained from http.ClientRequest.

I believe the Node types already have precedent for creating TS-only interface names that don't precisely reflect what's in the original Node docs, but make more sense in TS. Would that be useful here?

[orta]

Hi thread, we're moving DefinitelyTyped to use GitHub Discussions for conversations the @types modules in DefinitelyTyped.

To help with the transition, we're closing all issues which haven't had activity in the last 6 months, which includes this issue. If you think closing this issue is a mistake, please pop into the TypeScript Community Discord and mention the issue in the definitely-typed channel.

[thw0rted]

Trackback to #54920